Az Exchange Server telepítése 37. 
Dinamikus DNS 15. oldal 
Egységben az erő 44. oldal 
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Tanévzáró 


Mint minden rendes iskolában, a NetAcademia-ban is véget ér júniusban a tan- 
év. Egyfelől azért, hogy lélegzetvételhez jussunk mi magunk: bepótolhassuk el- 
maradásainkat, kimehessünk végre ügyfeleinkhez, akik január óta hiába várnak 
ránk... Másfelől azért, hogy az informatikus-társadalom is fellélegezhessen egy 
kicsit. Nincs elegük az állandó rohanásból? Ha nincs, ne hagyják olvasatlanul 
nyári számainkat, hisz most fogunk igazán belehúzni az újságírásba. A lelke- 
sebbek idén is, mint tavaly nyáron, vigyenek magukkal mindenhova egy 
tech.net magazint: tengerpartra, hegyek közé, völgyek közé. 

A tanévzáróra június 7-én kerül sor, ahova szeretettel várunk mindenkit! A 
rendezvényt elsősorban azok tiszteletére rendezzük, akik az elmúlt félév- 
ben tanfolyamon (NATE, Ugrósuli vagy hagyományos MOC) voltak nálunk, de 
természetesen azokra is számítunk, akik a komoly előadások, vagy éppen a 
komolytalan végkifejlet miatt érdeklődnek. Ezen az utolsó tanítási napon valami tanulnivalóval is 
szeretnénk fárasztani a jelenlévőket, de nem lenne az évzáró NetAcademiás, ha a vakáció örömére 
nem vennénk komolytalan fordulatot a nap végére. De lássuk az elejétől. 

Két előadás is lesz: az egyik elsősorban rendszergazdáknak szól, és az IPSec hálózati adatfolyam-titko- 
sítás lesz a témája. A Windows 2000-be beépített adatfolyam-titkosítás teljesen zökkenőmentesen, a 
háttérben dolgozva védi meg a vállalati adatokat az avatatlan szemek bepillantásától. Hiába ,ingye- 
nes", nagyon kevés helyen használják, mert túl bonyolultnak tűnik. Első ránézésre az is. 

A második inkább a fejlesztőkre kacsint: a régóta várt Design Patterns elmélettel ismerkedhetünk meg. 
Ez ahhoz kell, hogy megértsük a .net Framework filozófiáját (is). Tulajdonképpen az objektumorientált prog- 
ramozás kulcskérdése a tervezési minták ismerete: hogyan építsünk az egyedi objektumokból (téglák) házat? 
A témaköröktől nem kell megijedni: mindenről lehet úgy beszélni, hogy érthető legyen! E két előadás 
után majd jöhet a ballagás: akit érdekel, beballaghat velünk a CEU konferenciaközpont úszómeden- 
céjébe. (A víz hideg, de nem mély. Fázósaknak jelentem: szauna is van. A medencében koktélt szolgá- 
lunk fel. A ballagás nem kötelező, kihagyható.) Ezután következik az össznépi kolbászsütés, majd ér- 
zelgős búcsú egymástól, a tavasztól és a tanévtől. Részletesen: 


14:00-15:00 Biztonságos adatátvitel IPSEc-kel Fülöp Miklós 
15:15-16:15 Design Patterns Soczó Zsolt 
16:15-16:30 Tanévbúcsúztató beszéd Fóti Marcell 
Szünet 
16:30-17:30 
18:00-19:30 





Ballagás. Fürdőruha viselése ajánlott! 
Interaktív kolbászsütés a kertben 


A részvétel az extra szolgáltatások miatt sajnos nem ingyenes, hanem 10.000 Ft-ráfa, volt hallgatóink- 
nak 5.000 Ftx-áfa. Érdeklődni, jelentkezni az info Dnetacademia.net címen lehet - volt hallgatóinkat 
pedig személyesen is megkeressük. 


Fóti Marcell 
marcellf onetacademia.net 
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Windows.NET Server Beta 3 


Beta 3 állapotba érkezett a Windows kiszolgáló operációs rendszerek következő verziója. A korábbi 
tech.net számokban még csak Whistler kódnéven emlegetett terméknek már végleges neve is van: 
Windows.NET Server. Mi mégis a Whistler kódnév eredete után nyomozunk... 
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Farkasokkal táncoló 
Cluster a gyakorlatban (VI. rész) 


Elkanyarodunk a különböző típusú erőforrások taglalásától - az a néhány, ami még hátra 
van, megvár minket, amikor a nagyobb alkalmazások fürtösítését vizsgáljuk. Most azt 
vesszük górcső alá, miként viselkedik a fürt, ha a feladata a hálózati infrastruktúra ellátá- 
sa, címtárszolgáltatás, globális katalógus és egyéb, 
a Windows 2000 számára kritikus szolgáltatás biztosítása. 
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Exchange telepítés felsőfokon 

Hagyományos problémabemutató rovatunkban ma egy ritkán előforduló, 

ám tanulságos Exchange balesetet elemzünk, mely rögtön telepítéskor agyonvágja 

a világ legátgondoltabb rendszertervét is - ha megfelelően gyorsak vagyunk :). 

Megtudhatjuk azt is, hogyan távolítható el a félkész Exchange 2000 abban az esetben, 

ha a SETUP sem képes azt eltávolítani. 











Dinamikus DNS 941. rész) szsszezmmz 2 





Az előző részben bemutattuk a dinamikus DNS regisztráció működését. A regisztrációt asta) Le 
abban a formájában tulajdonképpen bárki elvégezheti, aki hálózati kapcsolatán keresz- ú 4 s 
tül képes felvenni a kapcsolatot a DNS kiszolgálónkkal. Szerencsére - Windows 2000 rleksszásó 1 
tartományon belül - a zónákon az adatok módosítását előzetes bejelentkezéshez köt- Es Iz I 
hetjük: ez a biztonságos zónafrissítés, azaz az , Only secure updates". Data iz storedin Active Directoy. 


Alom dynamic update? 





o Etheral 


Ingyenes hálózatanalizátor 


Cikkeinkben régóta hivatkozunk a Microsoft Network Monitorra, mint 
kötelező eszközre. Egy valamirevaló rendszergazda nem nagyon megy 
semmire egy rendes hálózatanalizátor program nélkül - mondjuk. 
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Microsoft 
Metadirectory Services 


(I. rész) 
Magyarországon is egyre több vállalat jut arra a felismerésre, hogy a heterogén infrastruktú- 
ra hosszú távú örökség is lehet - az egységesítés fontos, ám költséges és technikai kihívások- 
kal teli folyamat. Metacímtár kialakításával rövid távon is égető problémákat oldhatunk meg, 
miközben megtesszük a kezdőlépést hosszú távú egységes címtárstratégiánk megvalósítása felé. 
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IP Multicast 








Unicast és Broadcast 

Az IP Multicast az a hálózati forgalomtípus, mely a Unicast és Broadcast között 
helyezkedik el félúton, s amely szép új jövőnk alapja. 

E nélkül ugyanis nehezen lehetne elképzelni Pirx kapitány kalandjait, 

hisz ha nincs Multicast, nincs sokrésztvevős videokonferencia 





sem itt a Földön, sem a jövőben, az űrben. 
































.NET Akadémia 


Delegate-ek és események (IV. rész) 


Az előző számban megismerkedtünk a delegate-ekkel, és láttunk egy egyszerű példát a 
használatukra. Valójában sokkal többet tudnak, mint amit akkor felvázoltunk, képesek sok 
metódusreferencia meghívására is. Miután kiteljesítjük a korábban megkezdett atomreaktoros 
példánkat, rájövünk, hogy az ott végzett munkánk jelentős részét megspórolhatjuk multicast 
delegate-ek felhasználásával. 
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Az XML Schema (XII. rész) 

Számtalanszor hivatkoztunk már XML sorozatunkban az XML sémára, így hát itt az 

ideje, hogy közelebbről megismerjük. Ebben a részben áttekintjük az alap- 8 edfdobal Settngs 
ismereteket, és megnézzük az egyszerű típusok képzésének fortélyait. A következő 8 sen ese 
részben áttekintjük az összetett típusok kialakításának részleteit, a harmadik, e. je 
záró részben pedig tervezési mintákat nézünk át újrafelhasználható és jól JrTNLNBB jéljrolders 





olvasható sémák írásához, valamint megnézzük milyen eszközökkel lehet EEHETTTTZ 


ténylegesen kihasználni a sémák adta előnyöket. e. I 
; ae Az Exchange Server 
felügyelete 


Ismerkedjünk meg az Exchange 2000 felügyeleti eszközeivel, 
valamint nézzük meg az Active Directory Users and Computers 
snap-inbe integrált Exchange varázslókat! 


. ss! A Web Storage System 37. oldal 
BRGVAHBA Programozott levélkezelés 


Exchange sorozatunkhoz kapcsolódóan néhány cikk erejéig betekin- 
tünk a Web Storage System programozott elérésébe. Legelőször az 


I 
hé 
4— jea ADO-n keresztüli hozzáférést vizsgáljuk meg. 





Patchwork 
Adminisztráljunk Windows 2000-et 
Windows XP professional kliensről 








Egységben az erő 
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(VI. 


Farkasokkal táncoló 


Farkasokkal 


táncoló 


(VI. rész) — Cluster a gyakorlatban 


Elkanyarodunk a különböző típusú erőforrások taglalásától - az a néhány, ami 
még hátra van, megvár minket, amikor a nagyobb alkalmazások fürtösítését 
vizsgáljuk. Most azt vesszük górcső alá, miként viselkedik a fürt, ha a feladata 
a hálózati infrastruktúra ellátása, címtárszolgáltatás, globális katalógus és 
egyéb, a Windows 2000 számára kritikus szolgáltatás biztosítása. 


A farkasfalkára egy nagyvállalatot is rá lehet bízni - és ilyen, 
majdnem tisztán fürtökből álló rendszer már van Magyarországon. 


A feladat 

Nem sokkal a Windows 2000 megjelenése előtt azt a feladatot kap- 
tam, hogy készítsek egy tervet szerverparkunk megújítására. Több 
telephelyes vállalat a miénk, öt városban, hat helyszínen vagyunk je- 
len. Három üzemünkben egyenként 120-160 felhasználónk dolgozik, 
a kisebb irodaépületekben 10-40 munkatárs végzi napi tevékenysé- 
gét - az egyik kis telephely ezek közül az informatikai központ. 
Olyan kiszolgálókat kellett lecserélni, amelyek már majdnem négy 
éve üzemeltek, nem voltak bővíthetők, s mivel a felhasználók szá- 
mának növekedését nem tudták követni, itt is, ott is egy-egy újabb, 
PC-ből avanzsált társuk kerekedett. A , szerves" fejlődés eredménye- 
képp az egyik tartományvezérlő volt, a másik nem, az egyik nyom- 
tató-kiszolgálóként és Exchange levelezőként egyaránt funkcionált, 
a másikon csak egy SOL Server árválkodott - elég vegyes volt a kép, 
nem kell ezt ragozni. 

A feladat minket érdeklő része két egyszerű, egymásnak teljesen 
ellentmondó cél elérése volt: 

"0 legyen kevesebb kiszolgáló, és 

"0 legyen nagyobb a rendelkezésre állás. 
Miért ellentmondó célok ezek? Ha az ál- 
lománymegosztások három kiszolgálón, 
szétszórva működnek, még ha kiesik is az 
egyik, az állományelérés, mint funkció 
mégsem szűnik meg teljesen - nem 
mondhatjuk, hogy nincs semmi, legfel- 
jebb, hogy nem működik minden. Ha va- 
lamennyi közös mappát egyetlen vasra koncentráljuk, annak 
kiesése a teljes funkció elvesztését jelenti - ez botrány lenne. A 
kiszolgálók számának csökkentése viszont nemcsak azt jelenti, 
hogy kevesebb lesz belőlük, hanem azt is, hogy tervezetten 
ugyan, de eleve több funkciót látnak majd el. Ez még roszszabb 
helyzetet teremt: a megosztásokkal együtt az összes hálózati 
nyomtató is eltűnik! A megoldás a fürtszolgáltatás után kiált. 
Elkezdtem tehát a cluster után kutatni - ám leginkább olyan 
esettanulmányokat találtam, amelyek a sorozat első részében 
emlegetett tiszta konfigurációt tartalmaztak, vagyis amikor a 
fürtöt egyetlen feladatra, például egy ERP rendszer üzemelteté- 
sére használták. Ez nem jó hír, ugyanis telephelyenként 
legalább két Windows 2000 tartományvezérlő, két DNS- és két 
globális katalógus kiszolgáló dukál, nem is beszélve a DHCP és 
a WINS infrastruktúráról. Úgy tűnt, hogy a fürtszolgáltatás nem 
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A fürtözésre felkészített 
(angolul: cluster-aware) 
szolgáltatások szeretik 

és várják a rendelkezésre 

állás növelését. 


windows / 


visz előre, mert ugyan nagyobb megbízhatóságot nyújt, de több 
szervert követel. Vagy mégsem? 


tech.net - kimerítő mélységekig 

Elhatároztam, hogy mindent összegyűjtök a fürtökről, és ha le- 

het, akkor erre a szolgáltatásra építve készítem el a tervet. Elő- 

ször néhány alapvető problémát kellett tisztázni. 

Világossá vált, hogy a fürtszolgáltatás csak egy szolgáltatás a szer- 

veren, az tehát nem lenne újdonság, hogy emellett más szolgáltatá- 

sok is megjelennének. A kérdés csak az, hogy hogyan viszonyulnak a 

fürthöz. Irodalmazással kiderült, hogy sokféle lehet ez a viszony: 

"0 A fürtözésre felkészített (angolul: cluster-aware) szolgálta- 
tások szeretik és várják a rendelkezésre állás növelését. Szá- 
mos ilyen létezik: az állománymegosztások, a nyomtatósor, a 
WINS, a DHCP, az IIS, illetve a külön megvásárolható termé- 
kek, mint az Exchange, az SOL, a Biztalk stb. Az ilyen funkciók 
elkészítésekor a programtervezők számoltak azzal, hogy az al- 
kalmazás fürtre kerül, ezért beépítették a fürt támogatását. 

"2 Vannak fürtözésre fel nem készí- 
tett, de fürtözhető alkalmazások. 
Ezek általában nem Microsoft-ter- 
mékek, de szerkezetükben olyanok, 
hogy fürtözésük lehetséges. A ná- 
lunk működő J.D. Edwards vállalat- 
irányítási rendszer is ilyen, de gya- 
korlatilag a legtöbb, szabványos NT 
szolgáltatást létrehozó alkalmazás 
fürtözhető. 

2 Vannak nem fürtözhető alkalmazások, 

amelyek azonban működhetnek a fürtszolgáltatás mellett. A 

Windows 2000 önmaga is tartalmaz ilyeneket, például a DNS-t 

és a címtárszolgáltatást. Önálló termékként megemlíthetjük a 

SharePoint Portal Servert. 

Végezetül vannak olyan alkalmazások, amelyek ütköznek a 

fürtszolgáltatással, és nem telepíthetők Windows 2000-re, 

amennyiben a cluster működik. Ilyen a Systems Manage- 
ment Server minden verziója vagy harmadik féltől származó 
programok közül a Sotfware Metrics , Print Accounting 

Server" nevű terméke, amely a nyomtatási költségeket képes 

nagyon precízen költséghelyekre lebontani. 

Nos, történetünk szempontjából az a fontos, hogy minden, az 0- 

perációs rendszerrel kapott Windows 2000 szolgáltatás képes mű- 

ködni a fürt mellett, még ha a fürtbe nem is lehet bevonni. Ezek 
után nincs más teendő, mint megtervezni a teljes hálózatot. 


SCHE: ÚX. 


Fürtökre alapozott infrastruktúra 
Vállalatunk az alábbi alapvető informatikai szolgáltatásokat 
nyújtja minden telephelyen a felhasználóknak: 
8 Egységes címtár (beléptetés, hitelesítés) 
Pi Állományok központi elérése 
-8 Központi (kiszolgálón definiált) nyomtatók 
-0 Levelezés, kiszolgálón tárolt postaládákkal 
0 Internet, központi kijárattal 
0 Antivírus-rendszer, automatikus vírusadatbázis- 
frissítéssel 
0 Intranetoldalak (nem túl sok) 
Mindezek mellett vannak a felhasználók által nem ismert, de lé- 
tező szolgáltatások, mint a névfeloldás és a tallózás (DNS, WINS) , 
az IP cím adminisztráció (DHCP) és persze a mentés. Természete- 
sen nálunk is van vállalatirányítási rendszer, de a mi szemszö- 
günkből az nem infrastrukturális szolgáltatás, hanem alkalmazás 
- tehát most nem tárgyaljuk. (Egyébként persze az is fürtön fut.) 
A cluster nem olcsó, tehát csak bizonyos számú felhasználó ese- 
tén érdemes alkalmazni. Ökölszabályként azt mondhatjuk, hogy 
ha egy szolgáltatást 100 felhasználó igényel, akkor azt érdemes 
fürtösíteni. Nálunk négy ilyen telephely van, vagyis legalább 
négy egyforma fürt kellene, a következő feladatokkal: 
1-es állomás, nem fürtözött szolgáltatások: 
0 Tartományvezérlő 
"9 DNS, GC 
"0 Antivírus szoftver 
1-es állomás, fürtözött szolgáltatások: 
0 Állománymegosztások 
"0 Webszolgáltatások 
0 Nyomtatómegosztások 
0 DHCP, WINS 
0 Mentés 
2-es állomás, nem fürtözött szolgáltatások: 
0 Tartományvezérlő 
"0 DNS, GC 
0 Antivírus szoftver 
2-es állomás, fürtözött szolgáltatás: 
0 Levelezés (Exchange 2000) 
Egyszerűbb ezt egy ábrán megmutatni: 








Fájl, és Adatbázis- 


nyomtató alkalmazás 
szolgáltatás 
Erőforrás-tartalék Erőforrás-tartalék 
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5 Egy infrastruktúrafürt felépítése és funkciói 


Az adatbázisalkalmazás jelen esetben az Exchange 2000. (Tény- 
leg az! Ha valaki nem hiszi, járjon utána!) Minek nevezzük ezt a 
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konfigurációt? Aktív-passzívnak, vagy aktív-aktívnak? 
Tulajdonképpen mindkét állomás aktív, olyan feladato- 

kat lát el normál esetben, amilyeneket a másik nem. A 
szolgáltatások felől nézve azonban ez aktív-passzív szer- 

kezet, mert egy szolgáltatás (a fürtözhetők persze) egy időpil- 
lanatban csak az egyik kiszolgálón érhető el. Nevezzük el tehát a fen- 
ti alkotást hibrid konfigurációnak, ezzel mindenki elégedett lehet. 
Persze néhány apróságot még meg kell oldani. Ezek a problémák 
nem a fürt meglétéből fakadnak, hanem abból, hogy a funkció- 
kat rázsúfoljuk egy-két vasra. Ekkor is működik minden - csak 
egy picit oda kell figyelni a tervezéskor. 


DNS és globális katalógus 

Tiszta Windows 2000 környezetet tervezve nem kétséges, hogy a 
címtárral integrált DNS zónáknak több előnye is van, legyen te- 
hát a névfeloldás ilyen. A GC funkció viszont bizonyos esetekben 
ütközik az így konfigurált DNS szolgáltatással. A 0252695 számú 
cikk részletesen leírja a jelenséget, melynek lényege a következő: 
ha AD-integrált DNS zónákkal dolgozunk, és a tartományvezérlőnk 
TCP/IP beállításai a vezérlő DNS-ére mutatnak, akkor újraindulás- 
kor a globális katalógus szolgáltatás nem képes rekordokat re- 
gisztrálni a DNS Serverbe, mivel az csak később indul el. A leírás 
már adja is a megoldást: a tartományvezérlőnk abban az esetben 
nyújthat GC és címtárral egyesített DNS szolgáltatást, ha a TCP/IP 
beállításai nem a saját DNS-ére mutatnak. Azt ajánlom, hogy a 
fürtkiszolgálók DNS beállításait a következőképp adjuk meg: 

1. DNS kiszolgáló - a fürt másik tagja 

2. DNS kiszolgáló - a központban egy DNS szerver 

3. DNS kiszolgáló - önmaga 

Azért célszerű egy nem fürtbeli DNS kiszolgálót is megadni, 
mert előfordulhat, hogy a fürt másik tagja nem érhető el. Vég- 
ső esetben jobb, ha önmagához fordul a vezérlő, minthogy 
feladja a próbálkozást. 






































Hi CHC 


Ogyfelek 


Rendszergazda 


el 


5 A fürt TCP/IP beállításaiban a helyes DNS kiszolgáló sorrend 
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Az FSMO szerepek 

Kezdünk felépíteni egy szép, szimmetrikus világot, 

csakhogy a valóság ennél egy kicsit bonyolultabb. A 
Windows 2000 Serverek címtárszolgáltatásánál létezik öt 

olyan funkció, amelyet egy erdőben csak egyetlen kiszolgáló 

nyújthat. Ezeket angolul , Flexible Single Master Operation"-nek, 
nevezzük amit magyarul , rugalmasan állítható egyedi szerepkör"- 
nek fordíthatnánk. Ismertnek tekintve a fenti funkciókat, a követ- 
kezőket érdemés tudni, ha fürtözött környezetben dolgozunk: 
Az FSMO szerepköröket tétszőlegesen tehetjük bármelyik fürtál- 
lomásra, amely egyben tartományvezérlő is - egyetlen kivétel- 
szabály van csupán: az a kiszolgáló, amely globális katalógus 
szerver, nem lehet egyben az , Infrastructure Master" szerepkör 
tulajdonosa. A szabálynak nincs köze a fürtökhöz, egyébként is 
érvényes, de lassan formálódó szimmetriánkat tönkreteszi. Ha 
van olyan fürtállomásunk, amelyik ezt a szerepet viseli, akkor 
csak a társa lehet GC hordozó, önmaga nem. 
Amit még feltétlenül ajánlok az az, hogy nagybetűkkel véssük 
fel, hova tettük az egyedi FSMO szerepeket. Az FSMO funkciónál 
nem a működésük a gond, hanem a hiányuk és a helyreállításuk. 
Fürtök tervezésekor mindenképp ki kell dolgozni egy tervet arra 
az estre, ha egyik vagy másik állomás véglegesen felmondja a 
szolgálatot, és ki kell cserélni. A katasztrófa-elhárítási tervben 
kiemelt helyet kell kapnia az FSMO szerepeknek. 


Előnyök és hátrányok 

Bevallom, hogy a cikkben felvázolt infrastruktúráról még sehol sem 
hallottam. Egyes elemei megtalálhatók a tudásbázis cikkeiben, 
egészében azonban nincs publikált esettanulmány. Mindeddig. 
Mostantól azonban van. A leírt koncepció működik, méghozzá egy 
magyar nagyvállalatnál - lényegében háromnegyed éve probléma- 
mentesen. Joggal teszi fel a a kérdést a Kedves Olvasó : milyen elő- 
nyei és hátrányai vannak egy ilyen szerkezetű hálózatnak? 

Nos, előnyként jelentkezik az egyszer megvásárolt, de többszörö- 
sen élvezhető redundancia. Kettő, azaz kettő kiszolgálóval a fen- 
ti szolgáltatások magas rendelkezésre állásúvá váltak. A legalap- 
vetőbb szolgáltatások is betonbiztosak - csak a beállításokra kell 
egy kicsit ügyelni. Fontos, hogy a tartományvezérlők mindig kéz- 
nél vannak - így nem fordulhat elő, hogy a fürtszolgáltatás nem 
indul el, vagy a felhasználók hitelesítése nem történik meg. Ne 
felejtsük: a fürt rendelkezésre állása kisebb vagy egyenlő a tarto- 
mányvezérlő szolgáltatás rendelkezésre állásánál. Esetünkben ez 
nem probléma, míg ha a vezérlő külön kiszolgálón üzemel, és 
elérhetetlenné válik, akkor a felhasználók nem lesznek képesek 
hozzáférni a szolgáltatásokhoz, mert nincs hitelesítés. 
Hátrányként emlegetik tudásbázis cikkek, hogy a tartományve- 
zérlők többleterőforrást igényelnek. Erre az a válaszom, hogy 
Magyarországon semmiképp. Egy ilyen fürt amúgy is rengeteg 
tartalékkal rendelkezik - nem tapasztaltam problémát vagy las- 
sulást emiatt. Ha valaki nagyon aggódó alkat, akkor ajánlom ne- 
ki a ,tartományocskák" szakasz elolvasását. 

Sokkal inkább érdekes az alkalmazások (az Exchange, az SOL) és 
a tartományvezérlők egy állomáson való elhelyezése, de a 
0298570-es cikkben leírtakon kívül nem tudok gondokról. 

A cikkek nem sorolnak viszont néhány olyan hátrányt, amelyek 
mégiscsak léteznek. A kisebbik probléma, hogy olyan szolgáltatá- 
sok, mint a betárcsázás, nem fürtözhetők, biztonsági okokból pe- 
dig nem ajánlott tartományvezérlőkre telepíteni őket - tehát kilóg- 
nak a sorból. A nagyobbik probléma, hogy több memóriaéhes alkal- 
mazás azonos kiszolgálóra telepítése (pl. SOL és Exchange) mérete- 
zési és válaszidő problémákhoz vezethet. Absztrakt szabályt úgy fo- 
galmazok a fentiekből, hogy az infrastruktúra kialakítása a fenti 
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módon megoldja a rendelkezésre állás és a felfelé történő méretez- 
hetőség problémáját, szűkíti azonban a funkcióbővítés lehetősé- 
gét. Az előre megtervezett szolgáltatásokon felül nehéz újakkal 
kiegészíteni a fürtöt. Mindezen korlátok ellenére úgy gondolom, 
hogy az egyik legstabilabb rendszert sikerült létrehozni. 

Azt azonban nem szeretném állítani, hogy ez a tökéletes megoldás. 
Ha valakinek kiegészítenivalója, esetleg kritikai megjegyzése van, 
szívesen válaszolok a Netacademia tech.net levelezési listáján. 


Függelék: , Tartományocskák" 

Nem árt eléggé hangsúlyozni: ha egy nagy rendelkezésre állású 
szolgáltatás egy külső erőforrástól függ, akkor annak is nagy ren- 
delkezésre állásúnak kell lennie, különben a teljes rendszerben A- 
chilles sarkot hagyunk. Ez a helyzet a tartományvezérlőkkel is. Ha 
valaki aggódik amiatt, hogy egy tartományvezérlő funkció továb- 
bi terheket jelent a fürt számára, de szeretné biztosnak tudni a 
fürt indulását, később pedig a hitelesítést, annak a , tartományocs- 
ka" (angolul: domainlet) megoldást ajánlom. Ennek lényege a kö- 
vetkező: létrehozunk az AD erdőben egy új tartományt, és minden 
fürtállomást ebbe a tartományba telepítünk tartományvezérlőként. 
Ha a tartományban nem hozunk létre felhasználókat és egyéb AD 
objektumokat, akkor jelentősen csökken a címtárszolgáltatás erő- 
forrásigénye. Csak a globális katalógusok okoznak problémát - hi- 
szen azok továbbra is méretesek maradhatnak. Ezen azonban se- 
gíthetünk: helyezzük el az alábbi kulcsot minden vezérlő regiszt- 
rációs adatbázisában. Nem kell értéket adni -— a Windows 2000 
csak a kulcs meglétét vagy hiányát ellenőrzi. 


HKLMNSYSTEMNCurrentControlSetAControltLsav 
WIignoreGCFailures 


Ha a kulcsok már léteznek, akkor kikapcsolhatjuk a globális ka- 
talógus funkciót az , AD Sites and Services" mmc modul segítsé- 
gével az alábbi párbeszédpanelen. 





6 Ha nincs pipa, nincs globális katalógus sem 


Így minimális lesz a tartományvezérlők erőforrásigénye, és min- 
dig elérhetők lesznek. Több fürtnek elég egyetlen tartományt 
létrehozni. A megoldásnak ugyanazok a hátrányai, mint egy kö- 
zönséges újabb tartománynak: többletadminisztráció. 


Lepenye Tamás, MCSE 2000 
lepenyet omal.hu 


0237366 SMS: Microsoft SMS and Clustered Server Environments 

0174837 Microsoft BackOffice Applications Supported by MSCS 

0266650 BackoOffice Program Support on Windows 2000 
Datacenter Server 

0252695 DNS Server Generates Event 4011 

0223346 FSMO Placement and Optimization on Windows 2000 
Domains 

0281662 Windows 2000 Cluster Nodes as Domain Controllers 

298570 BUG: Virtual SOL Server 2000 Installations May Fail if 


Installed to Windows 2000 Domain Controllers 
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Exchange telepítés felsőfokon 


Hagyományos problémabemutató rovatunkban ma egy ritkán előforduló, 

ám tanulságos Exchange balesetet elemzünk, mely rögtön telepítéskor agyonvágja 

a világ legátgondoltabb rendszertervét is - ha megfelelően gyorsak vagyunk :). 
Megtudhatjuk azt is, hogyan távolítható el a félkész Exchange 2000 abban az esetben, 


ha a SETUP sem képes azt eltávolítani. 


Az itt elemzett telepítési probléma egyelőre nem szerepel a Micro- 
soft tudásbázisában (Knowledge Base). A tech.net magazin min- 
dig is élen járt a különböző exkluzív marhaságok publikálásában. 
Szerzőink közvetlenül a tűzvonalból küldik jelentéseiket! Hihetet- 
len kalandja volt? Írja meg nekünk: cikktipp(onetacademia. net! 


Az Exchange 2000 és az Active Directory 

Nemrégiben elindult Exchange 2000 sorozatunkban olvasható, 

hogy az Exchange 2000 - elődeitől eltérően - nem rendelkezik 

önálló címtárral, hanem az Active Directoryban tárolja beállítá- 
sait. Ennek megfelelően a kiszolgáló beállításainak változtatása 
is mintegy 138,799-ban az AD módosításán keresztül történik. 

Innen veszik az Exchange szolgáltatásai futási paramétereik új 

értékeit; ebben a System Attendant megfelelő végrehajtási szá- 

lai (Recipient Update Service, DSAccess, DSProxy, ADZMU) játsza- 
nak szerepet. Összefoglalva: 

"0 Ha az Exchange kiszolgáló beállításait módosítom a System 
Managerrel, valójában az AD egyik névterében, a Configura- 
tionban matatok. 

"0 Ha felhasználóknak készítek e-mail címet az Active Directory 
Users and Computerssel, akkor pedig a DC névtérben dolgozom. 


Replikációs ütközések kezelése az Active Directoryban 
A Windows 2000 címtára, az AD rengeteg újdonsággal szolgált előd- 
jéhez, az NT4-hez képest (hierarchikus, DNS 


alapú stb.). Ezek közül problémánk szempont- Az 
Active Directoryban 
öt olyan funkció van, 
mely nem végezhető fenyeget az elosztott módosításoknál véletlen- 
el tetszőleges 
tartományvezérlőn 


jából a többforrású (multimaster) replikáció 
érdekes: az AD tartományvezérlők bármelyi- 
kén módosítható az adatbázistartalom. Ha - 
netán - két gépen egymásnak ellentmondó 
beállításokat eszközlünk, a replikációs folya- 
mat kisimítja az apró ráncokat. Ha például 
egyszerre, egy időben két helyen módosítjuk 
Júzer Jolán leánykori nevének attribútumát, 
akkor a két változtatás közül az egyik (a korábbi) automatikusan 
elvész. Az automatikus konfliktusfeloldás gondoskodik arról, hogy 
az AD tartalma konzisztenssé váljon a tartományvezérlőkön. 

Ha az ellentmondás nem oldható fel automatikusan - akkor is 
feloldódik! 

Hozzunk létre egyszerre két helyen teljesen egyforma felhasználókat! 


te working with 


windows / 

















2 een : ts SEB 
ESESNESENSETETENETT 
Tree] [szervezet 2 objects 


Active Drectory Users 

5 3) ceg.hu £2 Joan zer 
6 CI Buttin £2 Joan IszerOCNF:eldfőaab-f177-42ae-a36f-édesbtZObSZF 
c. CI computers 


5 Két hajszálpontosan egyforma Júzer Jolán nem lehet a cím- 
tárban. Még ha egypetéjű ikrek is, valamiben biztosan eltér- 
nek. Ha nem a DNS-ben, hát a GUID-ben ;-) 


A konfliktus úgy oldódik fel, hogy az egyiknek a nevét megváltoz- 
tatja az AD: mögéír egy GUID-t. Ettől ugyan roppant ronda lesz a 
megjelenése, de egyedivé is válik! A fenti ábrán két Júzer Jolán 
veszett össze, s az egyikük GUID-vel a hátában végezte. 

Szomorú történet, de könnyű elkerülni: ne csináljunk ostobasá- 
got, ne hozzunk létre egyidőben teljesen azonos felhasználókat. 


FSMO (Floating Single Master Operations) szerepek 

Hogyan lehet garantáltan elkerülni az egymást ütő módosításokat? 
Mi sem egyszerűbb: le kell tiltani az elosztott módosítás lehetősé- 
gét. Az Active Directoryban öt olyan funkció van, mely nem végez- 
hető el tetszőleges tartományvezérlőn, ezeket csak kijelölt masinák 
hajthatják végre: a FSMO szerepek hordozói (PDC Emulator, RID Mas- 
ter, Schema Master, Domain Naming Master, Infrastructure Master). A 
Domain Naming Master őrzi például a gyermek- 
tartományok nevének egyediségét: valahány- 
szor új gyermektartományt hozunk létre, a DNM 
ad engedélyt adott nevű gyermek létrehozásá- 
ra. Ha egy kézben (gépen) van a döntés, nem 


szerűen bekövetkező ellentmondások felbukka- 
nása. Egyszerű, mint az egyszeregy. Kár, hogy 
csak ez az öt megkülönböztetett szerep létezik! 


Automatizált Exchange telepítés 

Ha a rendszerterv szerint 5-10 darab Exchange Server telepíté- 
sére van szükség, az ember kísértésbe esik, hogy automatikus 
telepítést használjon. Csak elkészítjük a megfelelő .INI fájlt, és 
hajrá! Párhuzamosan elindul nyolc telepítés a nyolc gépen. 

Mit is csinál az Exchange telepítő? Felépíti az Active Directory 
Configuration névterében az Exchange Organizationt; sok-sok 
objektumot hoz létre, többek között - ha nem talál ilyet - az 
Administrative Groups nevű tárolót, melybe majd a szerverünk 
bejegyzése kerül. Ezt alakítgatja: 
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5 Az Exchange 2000 fészket rak magának az AD Configura- 
tion névtérben. Ez a , természetfotó" ADSIEdittel készült. 


Ha jó a rendszerterv, akkor: 

1. biztosan egynél több tartományvezérlőnk van (mondjuk három) 

2. az Exchange Serverek nem feltétlenül tartományvezérlőn fut- 
nak (a várható terhelés elosztása miatt) 


A nyolc telepítő mindegyike AD-t keres ma- 


A Windows 2000 


pítés első felét megírják, majd (átneveződés után) egy másik, 
ugyanolyan nevűben folytatódik a művelet. Két lovat kellene 
megülni, ráadásul vágtatás közben! 

Reinstall? Nem megy! 

Deinstall? Nem megy! 

Ráinstall? Nem megy! 


Most akkor dobjuk ki a hardvert? Nem. Dobjuk ki az Exchange 
Servert! Mintha sohasem lett volna ott! 


3/a. A telepítőinformációk eltávolítása 

Registry editorral (regedt32.exe) töröljük a HKLM/SOFTWARE/ 
MICROSOFT/EXCHANGE kulcsot. Ezzel eltávolítjuk a telepítés leíró- 
információit. A SETUP.EXE a következő alkalommal úgy fog futni, 
mintha még sohasem lett volna Exchange Server ezen a gépen. 


De ez még nem elég: a félkész telepítés valószínűleg sikeresen felpa- 
kolt néhány szolgáltatást. Ezeket is ki kell venni a rendszer lelkéből. 


3/b. A szolgáltatások kitörlése 





gának, s véletlenszerűen rácsatlakozik a há- Support Tools Állítsuk le az összes MS Exchange szolgálta- 
rom tartományvezérlő egyikére, majd nekiáll eszközkészlet becses tást az Administrative Tools-sServices esz- 
a fészekrakási ceremóniának. Van már közzel, majd Registry editorral töröljük a 
Administrative Groups tároló? Nincs? Csinál darabja az ADSIEdit HKLM/SYSTEM/CurrentControlSet/Services 


magának egyet. Igen ám, de három tarto- 

mányvezérlő esetén bizony három ilyen kon- 

téner születik! Ajjaj! Mi lesz ebből! Hát replikációs konfliktus! 

Feloldása? A GUID hozzácsapásával! A végeredmény? 

"0 egy rendes, plusz két GUID-vel megspékelt nevű Admin Group 

"0 néhány félresiklott Exchange 2000 telepítés, mert elvették 
(átnevezték) a játékát... 


Az azonos Júzer Jolánokkal könnyedén elbánunk: csak DEL és 
vége. Ugyanez a sors vár nyilván a GUID végződésű Admin 
Groupokra. De mi legyen a (se)besült Exchange telepítésekkel? 
Lássuk sorjában: 


1. A GUID végződésű Admin Groupok lekaszálása 

A Windows 2000 Support Tools eszközkészlet becses darabja az 
ADSIEdit MMC modul. Ennek segítségével ugyanolyan könnye- 
dén törölhetünk a Configuration névtérben is, mint ahogy azt a 
DC Naming Contextben Jolánnal tennénk. Egy nyisszantás, és 
vége. 


2. Az Exchange Server objektum törlése 
A megmaradó, hibátlan AdminGroupból az ábra szerint töröljük 
ki a Servers alól a hibás telepítésű gép bejegyzését. 


[BEI 





6 A hibás, félrement Exchange Server nyomának eltüntetése 
a Configurationból 


3. A beszorult Exchange eltávolítása 

Azok a telepítések, amely alól kirántódott az Administrative 
Groups, még akkor is cigányútra mennek, ha közben a repliká- 
ció odahozza nekik az egyetlen, valódi konténert, mivel a tele- 
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alól az összes MSExchange kezdetű szolgál- 
tatás bejegyzését! 

Végül törölnünk kell a telepítési könyvtárat, de abba erőteljesen 
csimpaszkodik az Internet Information Server, ezért minde- 
nekelőtt állítsuk le az IISAdmin szolgáltatást, ami magával húz- 
za a mélybe az SMTP és az NNTP szolgáltatásokat. 


3/c. A fájlok törlése 

Most már törölhetjük a Program FilesXExchsrvr könyvtárat. (Már 
amennyit sikerül belőle. Nem baj, ha egy-két fájl marad, csak az 
MDBDATA könyvtár tűnjön el!) 


4. Telepítés 
Újraindítás után jöhet a SETUP.EXE! 


Az eset tanulságai 

"0 A rendszerek összetettsége miatt sajnos a legjobban végig- 
gondolt cselekvéssorozat is nem várt eredményre vezethet. 
Még az is előfordulhat, hogy mi vagyunk a világon a legelsők, 
akik belefutunk egy jó kis problémába. 

Az Active Directory címtár nem szent tehén. Ha a szükség 
úgy hozza, nyugodtan(?) mártsuk bele a késünket. (De előt- 
te számoljunk háromig.) 

I Az AD alapú alkalmazások viszontagságainak túlélése - bár- 
milyen meglepő - az AD alapos ismeretén áll vagy bukik. 
Az AD hibáknak mégsem tejles köre vezethető vissza DNS hi- 
bára. Csak az esetek 123,8290-ában igazolódik a DNS hiba. 
Legyen pilotrendszered. 


Fóti Marcell 
marcellf(onetacademia.net 
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Beta 3 állapotba érkezett a Windows kiszolgáló operációs rendszerek következő verziója. A 
korábbi tech.net számokban még csak Whistler kódnéven emlegetett terméknek már végleges 
neve is van: Windows.NET Server. Mi mégis a Whistler kódnév eredete után nyomozunk... 


A név kötelez 

Az új kiszolgáló esetében a dotnet kifejezés immáron nem csu- 
pán marketingfogásként jelenik meg a névben. (Mint korábban 
az ún. NET Enterprise Serverek némelyike esetében... Nem, nem a 
Host Integration Server 2000-re gondolok, ugyan... :-) 

Jó egy éve a Microsoft már belül is kemény szabályokhoz köti, hogy 
mi kaphatja meg a .NET jelzőt, és mi nem - a piciny kis utótagot 
csak az a szoftver illesztheti a neve végére, amely az Interneten 
hosztolható, provizionálható (automatizálható adminisztrációval 
rendelkezik) , és egyéb hasonló követelményeknek is eleget tesz. A 
korábbi ,buzzword", az XML támogatás, mint feltétel tehát önma- 
gában már nem elégséges. Ennek fényében nem lett , dotnet" a 
Windows XP, hiszen még nem tartalmazza a .NET Framework fejlesz- 
tői keretrendszert, ami a .NET Server-nek viszont már része lesz. 

A Windows.NET Server, mint megszokhattuk, egy kiszolgálócsa- 
lád, ám a Windows 2000-hez képest eggyel több tagot tartal- 
maz. Van természetesen Datacenter változat, mely a teljes 
kiépítést, a legbővebb szolgáltatást adja. Az ennél egy fokkal 
kevesebb funkcionalitással bíró változat neve .NET Enterprise 
Server lesz a korábbi Advanced Server helyett (visszatérve az 
dard Server mellett az új tag a Windows.NET Web Server válto- 
zat. Ne feledkezzünk meg az Embedded, vagyis a ,beágyazott", 
modulonként összerakható változatról sem, amivel úgynevezett 
.NET Server Appliance-ek készíthetők, pl. fájlkiszolgáló, vagy 
VPN célszámítógép, fekete doboz távoli felügyelettel. 


Whistler és Whistler anyja 

Mielőtt elmerülnénk a Beta 3-ban megjelent új funkciók tagla- 
lásában, előbb válaszolnunk kell két olyan fontos kérdésre, me- 
lyek a tech.net magazin szerkesztőségébe érkezett visszajelzé- 
sek szerint meglehetősen sokunkat foglalkoztatnak: mi is az a 
Whistler (1) (a bennfentesek számára síparadicsom, ahogy egy 
korábbi címlapborító hirdette), és vajon miért ez lett az új Win- 
dows kódneve (2)? 

Szerencsére mindkét kérdésre elsőkézből, abszolút tiszta forrás- 
ból kaptunk választ, melyet exkluzívan csak a tech.net magazin 
Kedves Olvasóival osztunk meg a következőkben. 

Whistler egy falu neve. A falu tőszomszédságában található egy 
hegy is, aminek szintén Whistler a neve. A falu határában mel- 
lesleg több hegy is található, mivel a falu egy völgyben épült. 
Mind a falu határának, mind a további hegyek egyikének jelen- 
tős szerepe lesz a továbbiakban. 

Whistler Village télen valóban egy síparadicsom, nyáron pedig 
golfparadicsom, az itt élők foglalkozási összetételére könnyen 
következtethetünk ezen tényekből. 
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I Got You Babe... 

Whistler angolul sípolót jelent. A helyiek szerint a név onnan ered, 
hogy nyáron (tehát a golfszezonban) a környező hegyeket ellepik a 
mormoták, akik különleges jellegzetességet kölcsönöznek a tájnak 
- valami furcsa módon ugyanis sípoló hangokat hallatnak az odúik- 
ból, amitől naphosszat visszhangoznak az erdők. (Arról nem tudni, 
hogy vajon Whistler lakossága ünnepli-e a Mormota-napot, amikor is 
a hagyomány szerint az odújából kibúvó, avagy nem kibúvó mormo- 
ta viselkedése alapján vonnak le messzemenő következtetéseket a kö- 
zeljövő időjárását illetően. Valószínűsítem, hogy igen...) 

Beta 3 állapotba érkezett a Windows kiszolgáló operációs rend- 
szerek következő verziója. A korábbi tech.net számokban... - no 
jó, csak vicceltem. (A szerző itt valószínűleg az , Idétlen időkig" 
című filmre utal Bill Murray főszereplésével, eredeti címe 
aGroudhog day" azaz Mormota-nap -— a szerk.) 

Whistler falu Kanadában található, Vancouver-től cirka 2 órányi 
útra kocsival. Történetünk szempontjából talán érdemesebb úgy 
fogalmazni, hogy a falu Seattle-től északra autóval jó 4 óra alatt 
megközelíthető. Ez nyomban sejteti a választ második kérdé- 
sünkre: a Seattle melletti Redmondban dolgozó Microsoft fej- 
lesztők számára remek hétvégi program kínálkoznak - télen sífel- 
ni, nyáron golfozni lehet. 





5 Sífelvonó a Whistler hegyre 


Brian Valentine 

A névadás hiteles és pontos körülményeit maga Brian Valentine me- 
sélte el - ő jelenleg a Windows fejlesztési csoport vezetője. A Ked- 
ves Olvasó már hallhatott róla, nemrég például az internetes The 
Register című informatikai bulvárlapban jelentek meg a Microsoft- 
ból kiszivárogtatott, a Linuxról írt belső céges körlevelei. . . 

Történt tehát, hogy az egyik Windows csoport fejlesztési Program 
Managerének kedve támadt ingyen síbérletet szerezni a Whistler- 
beli sípályákra. Tüsténkedett, forgolódott, míg munkája eredmé- 
nyeként az új Windows belső kódneve Whistler lett. Ezzel a hírrel 
nagy büszkén odaállt Whistler falu főpolgármestere elé, és az ide- 
genforgalmat fellendítő hírverésért szerény (ámde nem sértő) ju- 
talmul pusztán egy éves felvonóbérletet kért. 
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A polgármester persze elhajtotta. Végül is kit is ér- 
dekel, mi a kódneve egy PC-s szoftvernek? Hol hír- 
verés ez? Hol itt a faluimázs? Ugyan kérem... 
Habár a Program Manager pórul járt, a fejlesztők ettől 
függetlenül megszerették a Whistler nevet, hiszen kedvenc 
kirándulóhelyüket juttatta eszükbe. A Whistler utáni, következő 
Windows változatot (hiszen ennek fejlesztése is már régebben, a 
Whistler-rel párhuzamosan megkezdődött) éppen emiatt a falu 
melletti másik, a Whistler-rel szomszédos, talán még egy kicsit 
meredekebb sípályáknak otthont adó hegyről nevezték el. Ez a 
Blackcomb. Érdekesség, hogy a két hegy és a falu együtt egy kö- 
zös WhistlerBlackcomb marketing branddel, logóval rendelkezik, 


és saját weboldala is van: http://www.whistlerblackcomb.com 





5 Sífelvonó a Blackcomb hegyre 


Blackcomb 

A Blackcomb újabb mérföldkő lesz a Windowsok történetében. A 
Windows 2000 és a Whistler közötti váltás tulajdonképpen nem 
olyan nagy - mondjuk az NT 3.51 és a 4.0 közötti különbséghez ha- 
sonlítható - míg ha párhuzamot akarunk vonni, a Whistler-Black- 
comb lépés az NT 4.0 és Windows 2000 közötti ugrással mérhető. 
A Blackcomb tervezése során ugyanis szép lassan, de módszere- 
sen alapvető architekturális újítások tömege került bele a ter- 
mékbe. Ennek megjelenése (leghamarabb) 2004-2005 környéké- 
re várható. Hogy mégse legyen annyira sokkoló a sok újdonság 
hirtelen megjelenése (ahogyan az a Windows 2000 esetében 
volt; a hazai NT4-es társadalom talán épphogy csak mostanában 
kezd belejönni), időközben módosítottak a terveken. 
Megközelítőleg egy éve került nyilvánosságra, hogy a Windows 
.NET/XP és a Blackcomb között mégis lesz egy köztes Windows- 
változat, amely a Blackcomb terveiből egy kisebb részhalmazt 
valósít meg. Ennek a fejlesztésnek a kódneve: Longhorn. 
Longhorn szintén egy hegy Kanadában, bár Whistlertől egy ki- 
csit távolabbra esik - állítólag nagyon szép természeti tüne- 
mény. A kódnév azonban mégsem innen ered. Korántsem. 


Longhorn 

Akkor hát honnan? Ismét Brian Valentine-t hívjuk segítségül, 
remek Whistler-béli helyismeretével: 

Whistler Village határához elsétálva (mely tehát itt nyeri el végső je- 
lentőségét történetünkben) egy nagy térre jutunk, aminek jobb olda- 
láról a Whistler hegy felé indul egy sífelvonó, bal oldalán a Black- 
comb-gondola kabinjai repítik a sportolókat a magasba. A sífelvonók 
között, a tér köztes oldalán két lesiklás között megpihenhetünk egy 
kellemes kis kávézóban, a nyitott teraszon télen is zsibongó forga- 
tagban ücsöröghetünk egy picit - ennek a vendégmarasztaló helynek 
a neve: Longhorn Saloon. Egyszóval Longhorn tulajdonképpen egy 
kocsma... Brian Valentine-t szó szerint idézve: , Longhorn is the best 
place to stop between Whistler and Blackcomb." 

A redmondi fejlesztők egyébként fenemód jól érezhetik magukat, 
ha a fentiekhez még azt is hozzávesszük, hogy a Windows CE ope- 
rációs rendszer következő, .NET Framework alapú változatának kód- 
neve , Talisker". A Talisker egy kizárólag malátából készített (ún. 


Wörkiny vith 





vindaws Z 


single malt) skót whisky neve, a Skye szigetek vidékéről — az éde- 
sebb, mézes, vaníliás ízű, nem pedig a markáns, füstös fajtából. . . 
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5 A Longhorn bár terasza egy napos téli délután 


Végezetül: hogy jön mindehhez Whistler anyja? Nos, Whistler any- 
ja egy híres festmény neve - de ez már egy egészen már történet. . . 
Most már térjünk rá végre tényleg az új .NET Server funkciókra. 


Active Directory - még mindig 

Az Active Directory újdonságai eddig a tech.net magazin  min- 
den egyes Whistler beszámolójában terítékre kerültek, a Beta 3- 
ban azonban számos olyan új funkció is megjelent, amiről ed- 
dig még nem esett szó. 


Alkalmazáspartíció 

Egy korábbi számban már pedzegettük például az úgynevezett alkal- 
mazáspartíció (Application Partition) fogalmát, mely egy új Naming 
Context (NC) az Active Directoryban. Már Magyarországon is akad 
jónéhány példa olyan vállalatra, amely saját fejlesztésű alkalmazá- 
sának adatait az AD-ban tárolja. Ehhez a Windows 2000-ben min- 
denképp sémabővítés szükséges, aminek hátránya, hogy a változás 
az egész AD erdőben érvényes lesz. Számos helyen felmerült azon- 
ban az igény arra, hogy az egyedi alkalmazás adatai csak egy korlá- 
tozott területen, nem pedig az egész erdőben legyenek elérhetőek 
(erre jó példát nyújtanak a multinacionális cégek hazai leányai, ahol 
ugyan egy AD erdőben van a cég a bécsi, müncheni, párizsi, londoni 
központtal, ám a kis helyi fejlesztésű alkalmazás adatainak nem kel- 
lene az országhatáron túl is látszania). Ha ilyen, sémát bővítő válla- 
lati alkalmazást fejlesztünk, akkor az éles és a fejlesztői környezet 
szétválasztásának igénye is egy újabb ok arra, hogy két erdőből ál- 
ló Windows 2000 AD struktúra kialakítása mellett döntsünk. Két er- 
dő felügyelete pedig mindig nehezebb lesz, mint egyé. 

Ha többtartományos környezetben vagyunk (hazánkban szerencsé- 
re ez meglehetősen ritka, nagyon kevés helyen merülhetnek fel ko- 
moly technikai indokok az egytartományos modelltől való eltérésre) , 
tovább csökken a rugalmasságunk. Ebben az esetben az előbbi igé- 
nyeknek éppen a fordítottjával szembesülünk, azaz nemcsak saját 
tartományunkban, hanem az erdő tetszőleges tartományában is 
elérhetővé kell tenni az alkalmazásspecifikus adatokat. Ilyenkor az 
egyetlen megoldás a globális katalógusba (GC) való publikálás. Ek- 
kor sem tudunk azonban telephely- (site) vagy kiszolgálószintű 
szabályozást biztosítani az alkalmazásadatoknak: a GC kétállapotú 
- vagy van egy gépen példány belőle, vagy nincs. A replikát már 
nem tudjuk finomabban szabályozni, szűrni - nem tudjuk azt mon- 
dani, hogy ezen a GC-n csak X alkalmazás adatai érhetők el, míg 
egy másik GC-n csak az Y-é. Ha egy mezőt beveszünk (propagá- 
lunk) a GC-be, akkor az minden GC-ben megjelenik. 
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Filtered replika 

Ha a fenti szűrési feladat ismerős lenne, akkor mondjuk ki, hogy 
pontosan ezt valósítja meg az ún. , filtered replika", amit például 
a Novell NDS címtára használ a 8.5 változattól kezdődően. Az 
ilyen ,filtered", azaz szűrt replika használatakor minden egyes 
objektumról (vagy akár az objektum minden egyes mezőjéről) 
megmondhatom, hogy a sok replika közül melyikben legyen jelen, 
és melyekre ne replikálódjon. 

Nekem személy szerint tetszik az NDS filtered replika megközelíté- 
se. Egyetlen probléma van vele - rendkívül nehéz kezelni. Ember 
legyen a talpán, aki átlátja, hogy a címtárhierarchia sokezer objek- 
tuma közül éppen melyiket hova engedte bemásolódni, és hova 
nem. A replikációs topológia kialakítása sem egyszerű feladat, hi- 
szen lehet, hogy egy objektum számára megfelelő az A-B-C repliká- 
ciós útvonal, azonban egy másik számára ez már nem jó, mert előír- 
tuk, hogy B gépen őt nem tároljuk (ott ,,kiszűrtük") , így az ő , for- 
galma" nem haladhat B-n keresztül. Neki egész más útvonal kell, 
és ez így megy tovább, minden egyes egyedi szűrési beállításra. 
Technikailag rugalmas tehát ez a megoldás, azonban az életben 
gyakran nincs szükségünk ekkora szabadságra, mert nem tudunk 
mit kezdeni vele: nem tudjuk kézben tartani, átlátni. 


Az AD megoldás 

A versenytárs termékek felé tett kitérő után térjünk vissza a 
Windows.Net Server-hez. Hogyan oldja meg az új AD a fenti 
problémát? 

Nos, az alkalmazáspartíciót tetszőleges helyre replikálhatom a tel- 
jes erdőn belül - kiszolgálószíinten mondhatom meg, hogy az 
adott gép tárol-e egy példányt az adott partícióból, vagy sem. Az 
alkalmazáspartíció tehát nemcsak az adott tartományban, hanem 
az egész erdőben él (csakúgy, mint a GC). Tulajdonképpen egy 
plusz GC-t kapunk, azaz még egy erdőszinten független repliká- 
ciós topológiát alakíthatunk ki. 

Hogy jó példával járjon elöl, a Microsoft néhány alkalmazás (szol- 
gáltatás) adatát máris ebben az új partícióban tárolja - ilyen pl. 
az AD integrált DNS a Windows.NET Server-ben, illetve akár a RAS, 
RADIUS (IAS), DHCP adatok is az alkalmazáspartícióban kaphat- 
nak helyet (majd a végleges kódban kiderül...). A hírek szerint az 
ISA Server következő változata is az alkalmazáspartíciót használja 
majd - az Exchange oldaláról egyelőre nincs ilyen információ, én 
legutóbb februárban hallottam azt, hogy az AD csapat leült erről 
a témáról beszélgetni az Exchange fejlesztőkkel. No, de a Titanium 
(az Exchange következő változatának kódneve) még messze van... 
(elég sivár kódnév, különösen az előbbi történet után...) 


Független alkalmazás-címtárszolgáltatás 

Mellesleg, ha továbbgondoljuk a folyamatot, elképzelhető, hogy ez 
az alkalmazáspartíció egy, az AD-tól független önálló alkalmazás- 
címtárrá növi ki magát, míg az AD megmarad hálózati (105) cím- 
tárnak, együtt alkotva vállalati címtár (enterprise directory) megol- 
dást. Erre utal néhány jel: a .NET Serverben pl. az alkalmazáspartí- 
cióban bármilyen objektumtípust tárolhatunk (kivéve biztonsági ob- 
jektumokat: security principalis — felhasználók, csoportok, számítógé- 
pek). Ha a felhasználó azonosítását az AD végi, az alkalmazások 
konfigurációinak tárolása ettől függetlenül, egy másik infrastruktú- 
rán történhet - a különválasztott alkalmazáscímtárral így tulajdon- 
képpen elosztott registry(szerű) szolgáltatást kapnánk. Ez szerintem 
egész jól jönne pl. a .NET Framework-re írt alkalmazásoknak: egy 
rában, szövegfájlokban tárolja - ez hasznos a mobileszközök és 
egyéb más platformok közötti hordozhatóságot tekintve, azonban 
nehézkessé teszi a konfigurációk központi felügyeletét. 
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A függetlenedés talán még ott is látszik, hogy a ter- 

vek szerint a Domain Controller funkció (azaz maga 

az Active Directory) bármelyik kiszolgálón, depromo 
használata, vagyis telepítés nélkül szolgáltatásként, 
szervízként lenne futtatható (és leállítható!). Ezzel majd 
talán csak a ,kocsmában" (a Longhorn változatban) találkozha- 
tunk, a .NET Serverben egyelőre még nem. 

Mindez persze csak találgatás. A jelenlegi fejlesztések kísérleti 
továbbgondolása - a .NET Server funkcionalitása - egyelőre még 
nem végleges a Beta 3 változatban sem. 

Az biztosan látszik, hogy a jelenlegi vállalati rendszerekben a kü- 
lönböző alkalmazások címtárainak egységesítése egyre inkább 
égető feladat - egy ilyen címtárstratégia része lehet a Metadirec- 
tory szolgáltatás is. (Erről bővebben a MMS cikk első részében olvas- 
hatunk jelen számunkban) 

Hogy konkrétan mi lesz a .NET után, a Longhorn és a Blackcomb 
változatban, arról még a redmondi fejlesztőknek is csak vázlatos 
terveik vannak, 2005-ig még akár gyökeresen is megváltozhatnak. 
Ezekbe a tervekbe éppen ezért általában csak szigorú titoktartási 
nyilatkozatok (NDA -— Non-Disclosure Agreement) aláírása után en- 
gednek külső szemlélődőt betekinteni - a tech.net Ojság Kedves Ol- 
vasóinak így csak a folyosói pletyka és a találgatások maradnak... 


Telephelyek közötti replikáció 

Érdekes új funkció, hogy ha akarjuk, kikapcsolhatjuk az AD telep- 
helyek közötti replikáció tömörítését. Amerikában, úgy tűnik, bő- 
ven van sávszélesség, így ha valaki inkább a vonalat akarja ter- 
helni, a CPU-kon egy kicsit könnyíthet azzal, hogy nem zaklatja 
őket a be- és kitömörítéssel. Azt hiszem, mi még nem járunk itt... 
Mellesleg érdekes tudni, hogy a Windows 2000 sem tömöríti 
minden esetben a telephelyek közötti (intersite) replikációs for- 
galmat. Ha 10 Kbyte alatt van a replikálandó adat mennyisége, 
akkor nem történik tömörítés. Hogyan? A Kedves Olvasó 32k-ra 
emlékszik? Andreas Luther replikációs tanulmánya pedig 50k-t 
ír? A Windows 2000 Akadémián ráadásul 10 változást említettek 
küszöbértékként. No, és mit mond a Resource Kit? 

Nos, senki nem találná ki: valójában nincs ilyen bedrótozott 
korlát, azaz mégis van: 256 byte (nem kilobyte!). E felett a Win- 
dows 2000-ben az AD replikációs motor mindig (!) betömöríti 
az intersite replikálandó adatokat, majd összehasonlítja a tömö- 
rítetlen és a tömörített adatot. Ha az utóbbi kisebb, akkor tö- 
mörítve küldi, ha nem, akkor tömörítetlenül. Az átbillenési ha- 
tár néhány 10 KByte-nál van (nyilván változó, hogy éppen hol). 
A CPU-t tehát minden esetben terheli a tömörítés. 

Ez tényleg így működik?" - hallom is már az Olvasó hitetlenkedő 
kérdését. Azon a belső Microsoft fejlesztői levelezési listán is ezt 
kérdezték, ahol mindezt olvastam. , Ez tényleg így működik" - jött 
a válasz az egyik tagtól. , Itt van előttem a kód, onnan olvasom..." 
A tömörítés 32 Kbyte-os blokkokkal dolgozik, ez adhatta az 
egyik népszerű határ alapját - természetesen a blokkméretnek 
nincs köze ahhoz, hogy mikor lesz kisebb a tömörített adat, hi- 
szen a blokkot nem kell teljesen kitölteni a hívásnál. 

Andreas Luther és csapata pusztán empirikus úton, tesztekkel, 
mérésekkel elemezték a replikációs forgalmat, így jutottak a 
másik, széles körben elterjedt 50 KByte-os határ létezéséhez. 
(Intő jel ez kérem - mások például a SID-ek használatát vizsgál- 
ják hasonló empirikus módon, pusztán mérésekkel. Érdekes lenne 
tudni a kód ismeretében, hogyan is használja az NT/2000 ponto- 
san a SID-eket... De ez már egy másik téma). Ettől függetlenül 
Andreas Luther replikációs tanulmánya persze messze az egyik 
legjobb írás az AD témakörében [1] - ez a tévedés végül is tel- 
jes mértékben akadémikus, bár kétségkívül érdekes. 


20. 4. 


Az 


E ejag Juanuas LIN smopurm / 


le 


Windows.NET Server Beta 3 / 


13 





A .NET Server telephelyeken belüli replikációs tömöríté- 
si algoritmusa egyébként ugyanolyan hatékonyság mel- 
lett akár 2-7-szer gyorsabban működik, mint a Windows 
2000-es a korai tesztek szerint (empirikusan, ugyebár... :) 
A telephelyek közötti replikációs topológia kialakításáért 
felelős Inter-Site Topology Generator (ISTG) algoritmusában is 
újdonságokat hoz a .NET Server, azonban ez is azon (egyébként 
nem túl számos) funkciók egyike, amik csak a .NET Server natív 
üzemmódjában érhetők majd el. 


Globális Katalógus 

Ha már szóba került a globális katalógus - Windows 2000 ese- 
tén, ha egy újabb mezőt, objektumot propagálunk a GC-be (azaz 
módosítjuk a sémát), az teljes GC replikációt indít el, tehát nem- 
csak a változások, hanem az egész GC tartalma ismét elkezd ván- 
dorolni a hálózaton. A .NET Server esetén a GC attribútumok bő- 
vítésekor is megőrzi replikációs állapotát a katalógus, tehát ek- 
kor is csak a változások mennek át. 

A telephelyek közötti replikációs forgalom csökkentése - érthető 
okokból - úgy tűnik, egy kulcsterület. A Kedves Olvasóban persze 
ilyenkor felütheti fejét a kétkedés ördöge: nem gyanús, hogy amint 
az újabb termék megjelenése közeledik, úgy lesz a korábban opti- 
málisnak hirdetett Windows 2000 AD replikációnak egyre több ap- 
ró-cseprő hibája, amit természetesen a .NET Server majd megold? 
Nos, a helyzet egyáltalán nem ilyen vészes - ehhez ismét nézzünk 
körül a versenytársaknál. A Novell NDS-ben például nem létezik a 
telephely fogalma, azaz nem lehet a replikációt LAN-WAN sávszé- 
lesség szerint bontani. Bridgehead szerverek sincsenek, amik 
proxy-ként, gyűjtőként szolgálnának a WAN vonal jó kihasználá- 
sához. Mindenki mindenkivel replikál, az alábbi ábra szerint: 
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5 Az Active Directory replikációs topológiája könnyedén iga- 
zítható a vállalati vonalak sávszélességéhez 


Az NDS-ben éppen emiatt az egyik fő tervezési szempont az, 
hogy partíció lehetőleg ne nyúljon át telephelyhatáron. (Ves- 
sünk még egyszer egy pillantást a fenti ábrára a következmények 
megértéséhez! Remélem ez egy amolyan ,,aha" pillanat lesz 
(ahogy azt az amerikai mondja, mikor a fejére csap) azon Kedves 
Olvasók számára, akik cégénél az NDS replikációs forgalma csak 
úgy zabálja a vidéki vonalakat...) 

Az Active Directory fejlesztésekor ezzel szemben a fő cél az volt, 
hogy a logikai struktúra (a partíciók, azaz a tartományok) ter- 
vezése teljesen független legyen a fizikai topológiától (attól, 
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Active Directory 


telephely 2 





hogy milyen vonalak és transzportok állnak rendelkezésre a logikai 
struktúra alatt). Ugye emlékszünk még az alábbi ábrára a Win- 
dows 2000 TechNet előadásokról? (A mű egyébként Bátorfi Zsolt 
kollégám alkotása, szerintem nagyon erős szemléltető hatású rajz...) 
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Egyetlenegy olyan eset van, amire nem igaz ez a teljes függet- 
lenség: ha SMTP, azaz e-mail alapú (S-MIME segítségével titkosí- 
tott) transzportot akarunk használni RPC helyett az AD repliká- 
cióra, akkor ezt csak tartományok között tehetjük meg, tarto- 
mányon belül (intra-domain) nem. 

Ennek pediglen történeti okai vannak. Az USA védelmi hivatala 
(DOD - Department Of Defense) ugyanis már régóta Microsoft 
Exchange alapú levelezést használ (kb. 4-500 ezer felhasználó) , 
pontosabban az Exchange egy speciálisan a DOD részére készí- 
tett, módosított változatát az ún. DMS-t (Departmental 
Messaging System). A DOD-ben alapvetően csak az SMTP portok 
voltak nyitva szerte a belső tűzfalakon - ennek fényé- 
ben még 1998-ban, a Windows 2000 (akkor még NT5) 
tesztelésében segítő ügyfeleknek tartott JDP (Joint 
Development Program) konferencián megrökönyödve 
hallották, hogy a tervek szerint RPC lesz a transzport 
az AD replikációhoz. Egy DOD méretű (és biztonsági 
szintű) szervezetben egy újabb port kinyitásának éve- 
kig tartó tesztelési és engedélyeztetési fázisokon kell 
átmennie! Ennek reális esélyeit látva a Microsoft in- 
kább belefejlesztette a termékbe az SMTP transzpor- 
tot (400 ezer ügyfél, az mégiscsak 400 ezer ügyfél...) . 
Mivel a meglévő Exchange struktúra Organization-ök 
szerint volt NT4 tartományokra bontva, ez adta a mig- 
rációs utat is. Emiatt a DOD-ben csak a tartományok 
közötti replikációra kellett SMTP, mert ez ment át bel- 
ső osztályok közötti tűzfalakon. 

Persze kérdezhetjük, hogy ettől függetlenül miért 
nem került bele a tartományon belüli (intra- 
domain) replikáció SMTP támogatása a végleges 
Windows 2000-be, hiszen ha a DOD-nak nem is, de másnak 
esetleg lehetett volna szüksége rá? 

Nos, a választ talán több MCSE2000 is tudja: tartományon belül 
az AD replikációt nem csak az AD végzi, hiszen a csoportházirend 
objektumok (GPO, Group Policy Object) egyrészt az AD-ban, más- 
részt a SYSVOL megosztáson, a fájlrendszerben tárolódnak. A 
SYSVOL replikálását pedig a File Replication Service (FRS) végzi, 
amely csak RPC transzporton megy. Ahhoz, hogy tartományon be- 
lül is lehessen SMTP-vel replikálni az AD-t, az FRS-t kellett volna 
megírni SMTP használatára - ennek fejlesztésére, tesztelésére 
sem idő, sem igény nem volt már. 

Jó kérdés, hogy vajon a Windows.NET Serverben az FRS tud majd 
SMTP-vel replikálni? Kétlem. Talán már a DOD-nak sincs szüksége az 
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SMTP-re, most valószínűleg IPSec-et használnak. Komoly technikai 
indok nem igazán merülhet fel az SMTP mellett, így okafogyottá vá- 
lik ez a probléma. A történetet azért érdemes megjegyezni. 


Újabb kitérő a Utah állambeli Provo városába 
Visszakanyarodva az eredeti témához: az AD-ban tehát alapve- 
tően elkülönül a logikai és a fizikai struktúra tervezése. Az NDS 
8.5 -től kezdve a fenti nx(n-1) kapcsolat replikációs forgalmát 
úgy lehet csökkenteni, hogy nem egyszerre replikál mindenki, 
hanem szép sorban egymás után (az átvitt 
adatmennyiséget ez nem csökkenti, de a 
lökésszerű terhelést időben szétkeni). Bridge- 
head nélkül persze nem lehet jó megoldást 
találni - mert ahhoz telephelyeket kellene 
tudni létrehozni - de ezt sem lehet. A Novell 
nem ebbe az irányba indult el, hanem beve- 
zette a már korábban említett filtered replikát, amivel ténylege- 
sen szűrhető, csökkenthető az átvitt adatmennyiség. 

A globális katalógus Windows 2000-es replikációs forgalmából 
indultunk el - érdemes tudni, hogy az NDS-ben egyáltalán nincs 
a GC-hez hasonló partíció. Van egy különálló katalógusszolgál- 
tatás, aminek számos hátránya van: ez nem egy partíció, azaz 
nem replikálódik, és főleg nem mezőszinten (ahogy egyébként a 
többi NDS replika működik). A katalógust az NDS Catalog Service 
Manager ún. Dredger komponense pull módszerrel gyűjti össze. 
Mivel a változásokról ő nem kap értesítést, ezt a gyűjtést perio- 
dikusan meg kell ismételni, azaz folyamatosan nulláról fel kell 
építeni a katalógust (emlékszünk: a replikációs forgalom csök- 
kentéséből indultunk ki). Egy másik nagy hiányosság, hogy a ka- 
talógusba összegyűjtött objektumok (kivonatok) elvesztik ere- 
deti jogosultsági listáikat - a hozzáférési jog csak a teljes kata- 
lógus szintjén szabályozható, a katalógusban lévő objektumok 
szintjén nem. Ennek jelentős biztonsági vonzatai vannak. 

A Novell itt is más irányba indult el - a katalógusszolgáltatás 
továbbfejlesztése helyett ezt a feladatot is a filtered replika old- 
ja meg. Hiszen ha minden egyes objektumról és mezőről egyé- 
nileg szabályozhatom, hogy merre replikálódik, hol van jelen, és 
hol nincs, akkor nem kell katalógus; ez kiváltja a funkcióját (a 
kezeléséről mondottak azonban továbbra is igazak...) . 

A filtered replika koncepciója tehát alapvetően jó dolog - ha 
egy jó felügyeleti modellt lehetne kialakítani hozzá, bizonyos 


Az AD-ban 
elkülönül a logikai 
és a fizikai struktúra az úgynevezett 1-es funkcionalitási szint 
tervezése 


funkciókra még az AD-ban is el tudnék képzelni 

ilyen működést. Majd meglátjuk. 

Korábban hallhattunk arról, hogy a .NET Server-ben 
esetleg egy Domain Controller több különböző tarto- 
mány vezérlője is lehet (több partíciót, domain adatbázist 
is tárolhat) , ám a Beta 3-ban úgy néz ki, még mindig nincs meg 
ez a funkció, így majd talán a Longhorn vagy a Blackcomb tu- 
dását gazdagítja. Az NDS-ben egy fizikai kiszolgáló több NDS 
replikát is tárolhat. Csak a tényszerűség kedvéért. 


Sémabővítés 
Fóti Marcell tollából már korábban olvas- 
hattuk, hogy a natív Windows.NET AD erdő, 


használatához sémát kell bővítenünk. Ezt 
az Exchange2000-hez hasonló módon egy 
adprep.exe nevű kis eszközzel végezhetjük el. A /forestprep 
kapcsolóval a Schema Master FSMO szerepkörű tartományvezér- 
lőn, a /domainprep kapcsolóval pedig az Infrastructure Master 
FSMO szerepkörű DC-n kell lefuttatni (utóbbi a csoportobjektum 
egyetlen mezőben, listában tárolt csoporttagságainak replikáció- 
ját javító újítás miatt szükséges) (erről még a legelső Whistler 
előzetesben számoltunk be...) 


Május 15 - Windows.NET Server TechNet előadás 
Beszámolónkat a következő számban folytatjuk, ahol is megtudhat- 
juk, mit jelent a Release Candidate kifejezés, további újdonságokat 
olvashatunk az AD (pl. küzdelem a zombi objektumok ellen) , a biz- 
tonság, az NLBS és a Windows Update területeiről. A kíváncsiaknak 
addig is ajánlom a május 15-i, Lurdy házas, ingyenes TechNet sze- 
mináriumot a témában - jelentkezés a szokásos helyen [2]. 


Horváth Tamás 
MCSE2000 
Microsoft Magyarország 


A fent közöltek a szerző saját véleményét tükrözik, és semmilyen módon nem tekint- 
hetők a Microsoft Corporation hivatalos álláspontjának. 


A cikkben szereplő URL-ek: 


[1] http://www.microsoft.com/TechNet/prodtechnol/windows2000serv/deploy/ntopt11.asp 
[2] http://www.microsoft.com/hun/events/ 
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össz. 


A Windows 2000 


és a dinamikus DNS 


(II. rész) 


Az előző részben bemutattuk a dinamikus DNS regisztráció működését. A regisztrációt 
abban a formájában tulajdonképpen bárki elvégezheti, aki hálózati kapcsolatán keresztül 
képes felvenni a kapcsolatot a DNS kiszolgálónkkal. Szerencsére -— Windows 2000 tarto- 
mányon belül - a zónákon az adatok módosítását előzetes bejelentkezéshez köthetjük: 
ez a biztonságos zónafrissítés, azaz az ,Only secure updates". 


A biztonságos zónafrissítés 

Ha a DNS kiszolgálónk egy Windows 2000 tartományvezérlőn fut, és 
a zónánk adatait a címtárban tároljuk (azaz a zóna , Active Directo- 
ty-integrált") , a zóna önmaga, és minden egyes bejegyzés is rendel- 
kezik egy biztonsági leíró táblázattal, amiben meghatározhatjuk, 
hogy a zónával, vagy bejegyzésekkel ki és mit jogosult művelni. 
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o A biztonságos zónafrissítést csak a címtárba integrált zó- 
nákon engedélyezhetjük 


Alapértelmezett zónajogosultságok 
Korábban már bemutattuk, hogy a címtárintegrált zónák bejegy- 
zései valójában az Active Directory dnsZone és dnsNode objek- 
tumai. A zónák és rekordok így kapnak biztonsági hozzáférési 
listát (Access Control List — ACL): amikor a DNS konzolban eze- 
lemzőit módosítjuk. (A jogosultságlistát egyébként nyugodtan 
módosíthatnánk közvetlenül a címtárobjektumokon is, de a DNS 
konzolból azért talán kicsit kényelmesebb). 

A címtárban a rekordok (a dnsNode objektumok) a zónaobjektum 

(dnsZone) ,gyermekei". Így a rekordok létrehozását a szülőob- 

jektumon (a zónán) definiált jogosultságok korlátozzák; a lét- 

rejött bejegyzések pedig ugyaninnen öröklik a jogosultságlistá- 
jukat. A zónaobjektumon alapértelmezésben beállított érdeke- 
sebb jogosultságok a következők: 

"8 SYSTEM, Enterprise Domain Controllers, Domain Admins, 
Enterprise Admins, DNSAdmins: Full Control - azaz teljes 
hozzáférés, 

0 Authenticated Users: Create All Child Objects - gyermekob- 
jektumok (rekordok) létrehozása, 

8 Everyone: List Contents, Read All Properties, Read Permissi- 
ons - tartalom listázása, gyermekobjektumok jellemzőinek 
és jogosultságlistáinak olvasása. 
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5 A zónában bárki létrehozhat új bejegyzést 


A tartományvezérlők, a rendszer, illetve a rendszergazdák teljes 
hozzáférése, illetve a mindenki számára biztosított olvasási jog 
nem igényel különösebb magyarázatot. Az ,Authenticated Users" 
csoport magába foglal mindenkit, aki képes volt bejelentkezni a 
tartományba (ideértve a felhasználókat és a számítógépeket is: 
minden számítógép rendelkezik egy , felhasználói" fiókkal a tarto- 
mányban, melynek neve: zgépnév:$). A csoportnak definiált 
(gyermekobjektumok létrehozása) jog tehát azt jelenti, hogy 
bármely felhasználó, illetve számítógép létrehozhat bejegyzést a 
zónában, amennyiben sikerült bejelentkeznie. A regisztrációk zö- 
mét persze mindig a számítógépek végzik (emlékezzünk, a Win- 
dows 2000 már induláskor megpróbálkozik a regisztrációval). 
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Bár a regisztráció során létrejött rekordobjektum tulajdonosa a 
SYSTEM lesz, a regisztráló felhasználó (számítógép) Full Control 
jogot kap a saját bejegyzésére. Így azt a későbbiekben bármikor 
módosíthatja, vagy akár törölheti is, mások pedig legfeljebb az 
örökölt olvasási jogokat gyakorolhatják a rekordon. 


DNSUpdateProxy 
De mi van azokkal a rekordokkal, amelyeket a kliens helyett a DHCP 
kiszolgáló jegyez be? (Láttuk, van ilyen: a Windows 2000 DHCP Service 
szívesen bejegyzi a DNS-be azokat a címeket, amelyeket az önálló cím- 
regisztrációra nem képes ügyfeleknek - Win95/98/Me/NT - osztott ki). 
Az előbb kiderült, hogy a bejegyzett rekordhoz teljes hozzáférést — a 
tartományvezérlőkön és rendszergazdákon kívül - csak a bejegyzés 
létrehozója kap. Mi történik, ha a DHCP kiszolgáló néhány rekord be- 
jegyzése után meghibásodik, és a tartalék DHCP kiszolgálónk veszi át 
a helyét? Ha a tartalék szerver nem tartományvezérlőn fut, akkor nem 
lesz joga módosítani az előd által létrehozott rekordokat! 

Erre találták ki a DNSUpdateProxy csoportot, amelynek leírásában 
- kissé félrevezetően - az szerepel, hogy: ,DNS clients who are 
permitted to perform dynamic updates on behalf of some other 
clients (such as DHCP servers) ." (Azaz: ,, DNS ügyfelek, amelyek más 
nevében is regisztrálhatnak (például DHCP kiszolgálók) ") . 
Valójában a mások által beregisztrált rekordokat a DNSUpdate- 
Proxy csoport tagjai sem módosíthatják, hiszen - láttuk - a re- 
kordok jogosultságlistáiban ennek a csoportnak nyoma sincs. A 
csoport működésének valódi elve: a DNSUpdateProxy csoport 
tagjai által beregisztrált rekordokat később bárki módosíthatja! 
Ha tehát a DHCP kiszolgálónkat felvesszük ebbe a csoportba, ké- 
sőbb az általa regisztrált rekordokat bárki frissítheti, módosít- 
hatja, törölheti. 
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5 Egy DNSUpdateProxy-tag által bejegyzett rekord: aki 
kapja, marja! 


A DNSUpdateProxy csoport tagjai által regisztrált rekordok tehát 
egy plusz jogosultságot kapnak, ez pedig az Authenticated 
Users - Full Control. Elgondolkodhatnánk azon, hogy miért van 
szükség ilyen szintű engedékenységre: nem lenne-e elég, ha 
csak a DNSUpdateProxy csoport tagjai kapnák meg ezt a jogot? 
Nos, ez megoldaná a DHCP kiszolgáló kiesésének esetét, 
amennyiben a tartalék DHCP kiszolgáló is tagja a csoportnak. 
Nem oldaná meg viszont a másik fontos okot, ami miatt a 
DNSUpdateProxy csoportot kitalálták: ha ugyanis egy Windows 
NT 4 munkaállomást (ami nem képes önálló regisztrációra, így 
helyette a DHCP kiszolgáló regisztrál) frissítünk Windows 2000- 
re, a frissítés után az ügyfél már önmaga próbálkozna a bejegy- 
zéssel (ő azonban nem tagja a DNSUpdateProxy csoportnak). 
Ezért van szükség az Authenticated Users jogosultságaira. 

A dolog közben egy fontos veszélyt is magában rejt: soha ne ve- 
gyünk fel olyan kiszolgálót a DNSUpdateProxy csoportba, ami 
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egyben tartományvezérlő is! Ekkor ugyanis a tarto- 
mányvezérlő által regisztrált összes tartományi erő- 
forrás-rekord védtelenné válik (hacsak kézzel nem 
módosítjuk azok jogosultságait). A tartományvezérlőn 
futó DHCP kiszolgáló egyébként mindenképpen hozzáfér az 
erőforrás-rekordokhoz, hiszen az Enterprise Domain Controllers 
csoport jogosultsága 

megtalálható  minde- 


gyik bejegyzésen. Ez ...d DNSUpdateProxy 

persze nem segít a fen- csoport tagjai által 

ti (NT4-2W2K) eseten; e 2 

ilyenkor az egyik Peregisztrált rekor- 
dokat később bárki 


megoldás az, hogy 
kézzel töröljük a DNS- L z e 
as áá AG módosíthatja 


ből a DHCP által re- 
gisztrált ,régi" rekor- 
dot. A másik megoldás kézenfekvő: a DHCP kiszolgálót ne tele- 
pítsük tartományvezérlőre. 


A biztonságos DNS frissítés szabványai 

A Windows 2000 dinamikus DNS szolgáltatása nem az RFC 2137 
(Secure Domain Name System Dynamic Update), és ugyancsak 
nem az RFC 2535 (Domain Name System Security Extensions) 
alapján működik. Ehelyett egy olyan módszert használ, ami ké- 
pes összekötni a Windows 2000 tartományban amúgy is rendel- 
kezésre álló Kerberos felhasználóazonosítást és a dinamikus DNS 
frissítést: ez pedig az úgynevezett GSS-API (Generic Security 
Service Application Program Interface, RFC 2078 [1]). A GSS-API 
tulajdonképpen egy olyan keretrendszer, ami lehetővé teszi tet- 
szőleges felhasználóazonosítási megoldás (esetünkben a 
Kerberos) tetszőleges hálózati szolgáltatással való összekapcso- 
lását (esetünkben a DNS-sel). Ehhez mindössze két új DNS re- 
gisztrációs erőforrásrekord-típust kellett definiálni, ezek a TKEY, 
illetve a TSIG erőforrásrekordok (RRs — Resource Records). 

A felhasználóazonosítást mind az ügyfél,- mind a kliensoldalon a 
GSS-API, azon belül is a Windows 2000 Kerberos biztonsági al- 
rendszere végzi. A sikeres felhasználóazonosítás után az ügyfél a 
kapott Kerberos jegy segítségével előállít egy speciális (TKEY) re- 
kordot tartalmazó , bejelentkező" DNS csomagot. A TKEY lekérde- 
zésre a kiszolgálótól TKEY válaszrekord érkezik; ebben a pillanat- 
ban az ügyfél azonosította magát a kiszolgáló felé és viszont; a 
TKEY rekordban kapott adatok segítségével pedig a további kom- 
munikáció (a valós címregisztráció) minden egyes csomagja digi- 
tálisan aláírható. Ez a digitális aláírás utazik a TSIG (Secret Key 
Transaction Signature) rekordokban. 


A Windows 2000 biztonságos DNS frissítése 

Akárcsak az előző alkalommal, a Network Monitor illetve a jelen 

számunkban bemutatott ingyenes Ethereal program segítségével 

megtekinthető elkapott hálózati forgalmak letölthetők a [2] cím- 

ről. A probootdyn e f.cap fájl egy tartományi tag (Windows 2000 

Professional) indulásakor generált hálózati forgalom egy részét 

mutatja. (A $ jellel jelölt számok a csomagok sorszámát jelölik) : 

H1: a kliens lekérdezi a szülőtartomány SOA rekordját, hogy 
abból kiolvashassa a tartomány elsődleges zónáját kezelő 
DNS kiszolgáló címét (a dinamikus frissítéseket ugyanis — 
mint tudjuk - ennek kell küldeni) í 

2: megérkezik a kiszolgáló válasza, benne a DNS kiszolgáló 
IP címével 

843 és H4: 
a címregisztrációhoz szükséges prerekvizítumok lekérde- 
zése, és a kapott válasz (részletesebb magyarázatukat lásd 
az előző számban) 
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47: a kliens elküldi a prerekvizítumok alapján 
előállított re- 
gisztrációs kérelmet a kiszolgálónak, benne a saját 
címével. 
... eddig a módszer megegyezik a hagyományos frissítéssel. 
Ekkor jön viszont - derült égből - az ,Operation Refused" (48): 


Í 





[DNS öza-Dyn Upa Rezp. PRE/UPD records to uökpro.falarraz hu. of type Canonical nana 


: Ouesy Kdenzítter 2 4 (öx6) 
- Responce, ÖpCode - Dyn Upd, RCode 
: 21 ton 


ásíte Section Entry Count e 2 (0x2) 
ection Enery Count s 1 (01) 

Records Count " 0 (0z0) 
: falatrar.hu. of type 50A on class INET adár. 
te: uzkpro. falarraz.hu. of type Canonical name on class Unknown C1asj 
T Update: uZkpro. talarrax.hu. of type Host Addr on class INET addr. 





















o A kiszolgáló elutasítja a névtelen regisztrációs kérelmeket 


A Windows 2000 ügyfél ekkor megpróbál bejelentkezni. A H9-es 
csomag egy Kerberos jegy-kérés (KRB TGS REO) a server.falat- 
rax.hu kiszolgáló DNS szolgáltatásához: 


e Port: Unknown (59); Length " 1290 (Oz$0A) 


2 § (025) 
RB TCS REG 


" KDC-Reg-Body (reg-bodyt4)) 


Realn Nane" 
: Server Name s DIS/zerver, falatraz 
Axpiration Date " 09/13/1037 0Z:48:Ö$ UTC Time Zone 
Pandom Munber " 2100107035 (O27D2DL71B) 
ÖKerberos: Supported Eneryptáon Types 





5 Kerberos jegykérés (bejelentkezés) 


A Kedves Olvasó sajnos valószínűleg ebben a formában nem fog- 
ja látni a Network Monitor által elfogott csomagot, ugyanis a 
Kerberos kommunikáció értelmezéséhez szükséges bővítmény 
nyilvánosan nem hozzáférhető. Arról azért meg lehet ismerni a 
Kerberos kommunikációt, hogy a (Kerberos kulcselosztási szolgál- 
tatást - KDC - futtató tartományvezérlő) kiszolgáló UDP 88-as 
portjára csatlakozik, illetve a válasz is onnan érkezik. (Az Ethereal 
képes a Kerberos csomagok visszafejtésére is). A kérésben azt lát- 
hatjuk, hogy a munkaállomásunk jegyet (hozzáférést) kér a ser- 
ver.falatrax.hu kiszolgáló DNS szolgáltatásához. A t9-es válasz- 
ban már érkezik is a Kerberos jegy. Az ügyfél ezt a jegyet eltárol- 
ja, és a segítésével előkészíti a TKEY rekordot. Mivel a TKEY re- 
korddal kibővített DDNS kérés mérete már meghaladja az egyet- 
len UDP csomagban átvihető adatmennyiséget, ezért a kliens TCP 
csatornát (!) épít a kiszolgáló 53-as portjára (411-413). A 
felépült csatornán pedig elküldi a GSS-API bejelentkezéshez szük- 
séges speciális DNS csomagot, benne a TKEY rekorddal (414-415): 





[NET OZTOKET STT Ty Tor PIOFJJOTTT7Ö-T ST type SETt Key TItBT sm ETAzT THET Ada 
DS: TCP Length e 2547 a) 

lé (02704) 

de - $td Ory, PCode - Ho error 

21 (021) 

54 (01) 

DUS: Hame 2 0 (020) 

TNS: Addítáonal Records Count e 0 (0x0) 

aDNIS: Üuestion Section: 910$33066770-2. ot type Sert Key EStDl on elass INET adár 
DNS: Ouestácn Hane: 910523066770-3. 
DNS: (uestion Type " Secret Key Eszablishment 
DNS: Cuestion Class: 5 














Addíttonal Resource Data " 03 67 77 73 09 6b 69 63 72 6F 72 6? 66 74 03 63 6F 6b 


5 A DNS bejelentkezés, benne a TKEY rekorddal 


A kiszolgáló válasza a H17-es csomagban érkezik: ha nem történt hi- 
ba, a válasz már digitális aláírással (azaz egy plussz TSIG rekorddal) ki- 
bővítve érkezik. Innentől kezdve az ügyfél és a kiszolgáló azonosítot- 
ta egymást, és a bejelentkezést követően (hála a digitális aláírásnak) 
más már nem avatkozhat bele a kommunikációba. A bejelentkezés 
után a TCP csatornára már nincs szükség, azt be is zárjuk (418-421). 
Más már nincs is hátra, mint beregisztrálni a címrekordot: a TSIG re- 
korddal felturbózott regisztrációs kérést a H22-es csomagban látjuk: 
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55HS- OZ7IFD:Byn Upd PBE/UPD records to uökpro.falatraz.hu. of type Canonical nazi 
DíIS: (uery Identifier " 30717 (0277FD) 

DNS: DNS Flags " Cuery, OpCode - Dyn Upd, RCode - Ho error 
DNIS: Zone Count " 1 (021) 
DüIS: Prereguisíte Section Entry Count " 2 (0x2) 
DHIS- Update Section Entry Count 1 (021) 
DNIS: Addítícnal Records Count " 1 (021) 

£ eype S0A on class INET addr. 

az.hu. of eype Canonical nane on class Unknowm 
type Host Addr on elass INET addr 

DNS Resource Nane: u2kpro. falatraz.hu. 

DNS: Resource Iype " Host Address 








length e 72 (0248) 
DNIS: Additional Resource Data " 039 67 73 73 09 6D 69 63 72 6F 73 6F 66 74 03 6l 





a Secure Dynamic DNS Update: digitálisan aláírt DDNS re- 
gisztrációs kérés 


A kiszolgáló ellenőrzi a digitális aláírást, és a $23-as csomag- 
ban - ugyancsak aláírva - visszaküldi a választ. Ezzel a bizton- 
ságos dinamikus DNS frissítést véghezvittük. 


Rekordéllettartam, automatikus szemétgyűjtés 

A DNS zónákban regisztrált rekordokat azok gazdája nem min- 
den esetben törli onnan. A Windows 2000 DNS kiszolgálója beál- 
lítható úgy, hogy automatikusan törölje a régi, régóta nem fris- 
sített rekordokat. Az automatikus törlés (scavenging) alapértel- 
mezésben nincsen bekapcsolva (általában nincs is rá szükség); 
ha használni szeretnénk, kiszolgálónként, illetve azon belül zó- 
nánként is engedélyezhetjük: 










CTETZTEETTETTT ET NEEENHEE TET 1. TETTETETT] 
WINS] zonettandem 7] Scan 17 Scavenga atáló tösövace tecorde 
General] StatofáuthortyiOAI —] Name Server [7 Morereshinterval 
The tíme between tha most receni telresh ot a cord times 
Status Rurring [sa the momertt when the tmestamp may be relreshed agan. 
Type AcííveDíroctoyíntegzated /  Norehezh irterval 7 [dovr 7] 
Data ia stered in Active Directogy ezeti Tr" 
,  Thetime between the earkest moment when a record tírersi 
17 sésérozá Thagelth mtarvál nyal be lenget hár to 
rű m 
Alom dgynanóc izpdatez? Ör zecve update n 
To net agngyscavengna propattas. ebek Agng. ra] 


5 Az automatikus szemétgyűjtés beállításai 


Az engedélyezés után a kiszolgáló minden dinamikusan létreho- 

zott rekordot időbélyeggel lát el. Ez az időbélyeg frissül minden 

módosítás esetén, illetve bizonyos esetekben akkor is, ha a re- 
kordhoz tartozó IP cím nem módosul, de a kliens frissíti azt. Az 
engedélyezéskor két időszakot kell meghatároznunk: 

0 No-refresh Interval: ezidő alatt a rekordok időbélyege nem 
frissül, még akkor sem, ha az ügyfél regisztrálni próbálja a 
meglévő bejegyzést (természetesen, ha az IP cím megválto- 
zik, akkor igen). Ezzel csökkenthetjük a felesleges címtár- 
replikációs forgalmat. 

"8 Refresh Interval: ezalatt az időszak alatt a rekordok időbé- 
lyege frissülni fog. A Refresh Interval a No-refresh Interval-t 
követi, és az automatikus szemétgyűjtés csak a Refresh 
Interval lejárta után következhet be: 


Frisstés nékül időszak Frisstésiidőszak 


övélyeg (io-Retrethirterval)  (Retrezhinterval) 
(arrekord létrejötte vagy utolsó ttisstése) [7 aj: 
Fnsstés ektaztva 
Fnsstés eltogadva [—— 
A nem tnastett rekordok törölhetők 7 


5 Az automatikus szemétgyűjtés időzítése 





202: 04. 


Alapértelmezésben mindkét időszak 7 nap, tehát az árva rekor- 
dok 14 nap után törlődnek majd a DNS kiszolgálóról. 

A rekordok időbélyegét megtekinthetjük a rekordok tulajdon- 
ságlapján, de csak akkor, ha a DNS konzol View menüjében elő- 
zőleg engedélyeztük az , Advanced" nézetet: 





ESZTET NEEE KEETET 22 


Hosttáj ] 


Prent domain 
fdatrazha 


Host luses parent domain ú lett blankk 








IT Update associated pointer [PTAJ record 


(7 Delete this record when ít becomes stale 


F——— 


Record time stömp; 





5 A rekordok időbélyegei 
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A lényeg a ,Delete this record when it becomes 

stale" jelölőnégyzet: ha ez engedélyezve van, akkor 

a beállított idő lejárta után a kiszolgáló a rekordot 

törölheti az adatbázisból. Ugyanitt megnézhetjük a re- 

kord időbélyegének aktuális értékét is. Az ábrán látszik, 
hogy a , server" rekord automatikus törlése nem engedélyezett. 
A DNS kiszolgáló ugyanis nem fog törölni olyan rekordokat, 
amelyek még az automatikus szemétgyűjtés bekapcsolása előtt 
kerültek bele az adatbázisba. Persze, ha akarjuk, a rekordokon 
ezeket a jellemzőket akár kézzel is beállíthatjuk. 


Fülöp Miklós 
mick onetacademia.net 


A cikkben szereplő URL-ek: 
[1] http://www.ietf.org/rfc/rfc2078.txt 
[2] http://technet.netacademia.net/download/ddns/ 


Legyen Ön is BUG Hunter! 

A hivatalos egyenruhát képező 
speciális vadásztrikó kiérdemléséhez 
mindössze annyit kell tennie, hogy 
az Ön által felfedezett BUG-okat 
levadássza! Hogy hol találhatja 
Őket? Ismeri a természetüket, 
természetesen bárhol a magazinban. 
A vadászat eredményéről értesítsen 
minket, hogy mielőbb elküldhessük 
Önnek a hivatalos egyenruhát. 
Szerencsés vadászatot! 


Szabályzat: 

1) Minden hiba ELSŐ felfedezőjének 
jár póló. 

2) Hibajelentés a weben: 


3) A vadászat minden számnál a 
következő szám megjelenéséig tart. 
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Ethereal 





Ethereal 


. Ingyenes hálózatanalizátor 


Cikkeinkben régóta hivatkozunk a Microsoft Network Monitor-ra, mint kötelező 
eszközre. Egy valamirevaló rendszergazda semmire sem megy 
rendes hálózatanalizátor program nélkül - mondjuk. 


Egy pici baj van csak: a Microsoft Network Monitor csak 

a Windows NT/2000 Server-től , felfelé" érhető el, és ab- 

ban is csak a butított, ,lite" verzió. Ha a teljes változa- 

tot szeretnénk - legálisan -, akkor bizony meg kell ven- 

nünk az SMS Server csomagot, mert a Network Monitor abban bújt el. 
Most bemutatunk egy olyan ingyenes eszközt, ami nagyon sok 
tekintetben felveszi a versenyt a Network Monitor-ral, sőt, ese- 
tenként le is körözi azt. A legújabb változat (forráskódostul) az 
[1] címről tölthető le, és a Windows-os (mármint Win95, 98, Me, 
NT, 2000, XP és .NET) verziókon kívül találunk itt szinte minden 
operációs rendszerhez: nem kivétel a Linux, a Solaris, a MacOS, 
a FreeBSD, az AIX és még sok más sem. 


A WinPCap driver 

A programnak működéséhez szüksége van egy hálózati eszköz- 
meghajtóra, ami a hálózat közvetlen elérését biztosítja számára. 
Ehhez a [2] címről le kell töltenünk - az ugyancsak ingyenes - 
WinPCap telepítőkészletét. A Windows XP és .Net Server legalább 
a 2.3-as verziót igényli - a cikk írásának pillanatában épp ez a 
letölthető változat. A meghajtó letöltése és telepítése egy per- 
cig sem tart. Ha ezzel megvagyunk, már telepíthetjük is az Ethe- 
real-t. Az Ethereal elindítása után a következő kép fogad minket: 


Fi play Tools 


Destination 
7 user-dns-tvnet-hu DNS Standard guery A www. Inder.hu 
23 Ons — Standard guery response A 217.20.134.241 
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3 28 68 69 99 14 





5 Az Ethereal főképernyője 


Az Ethereal főképernyője (hasonlóan a Network Monitor-hoz) há- 

rom fő részből áll: 

"0 A felső harmadban az elfogott csomagok listáját látjuk. Min 
den sor egy csomagnak felel meg. Ha egy sorra kattintunk, a 
képernyő többi részén megjelenik a csomag kifejtett változata. 

"0 A középső harmad a kiválasztott csomag (helyesebben keret, 


working with 





windows / 


frame") részletes, hierarchikus, böngészhető tartalma. A pro- 
tokollanalizátorok ide fejtik nekünk vissza azt, amit az adat- 
folyamból kinyertek. Ha itt egy sorra kattintunk, az alsó har- 
madban kijelölődik a hozzá tartozó adatfolyam. 

"0 Az alsó harmad a csomag hexadecimális tartalmát mutatja. 


A képernyő alján található Filter: gomb és mező a szűrés beállí- 
tására szolgál; később azt is bemutatjuk. Előbb azonban fogjunk 
el valamilyen hálózati forgalmat: ehhez a Capture... menü 
Start... parancsát használhatjuk. 


A hálózati forgalom elfogása 

A parancs hatására megjelenik a csomagok elfogásának paramé- 

tereit firtató dialógusablak: 

ESZT 5 A csomaggyűjtés para- 
Capture méterei 


interface: fDemcetPacket I6CF53526-29C4-105€. /] 
limit each packet to FE 3 bytes 


Az ,Interface" sorban vá- 
lasszuk ki, melyik hálózati 
csatolóról szeretnénk ada- 
tot gyűjteni. Ha ez a lista 
üres, valószínűleg nem 
volt sikeres a WinPCap esz- 
4 ő v közmeghajtó telepítése. 
sel áe ak, Ha a lista tartalmaz soro- 
kat, akkor sincs könnyű 
dolgunk, ugyanis itt csak a 
hálózati csatolók" belső 
azonosítóit látjuk. Ha tele- 
rr Enable transport name resolution pítettük a Windows 
55 8 E 2000/XP Support Tools 
programcsomagot (a Win- 
dows telepítő CD-ken rátalálunk a /Support/Tools alkönyvtárban) , 
akkor adjuk ki a 


1 Capture packets in promiscuous mode 
Fiter 


Capture file(s) 
File: 


1Use ring buffer B 3 
Display options 
J Update list of packets in real time 


A packet(s) captured 
-) kilobyte(s) captured 


3 second(s) 


15top capture after 





1Stop capture after 
Name resolution 
r Enable MAC name resolution 


rr Enable network name resolution 


netdiag /debug /test:ipconfig 


parancsot. A megjelenő válaszban keressük ki az alábbi (Per 
Interface Results") részt: 


EBOZ. 04. 








Netcard gueries test . . . : Paszed 


Ethernet 
tuilight 
Vinbond WB9C948-Based Ethernet fidapter (Gen 


: 80-40-P6-4€-EC-EE 
: No 


ves a 





fidapter type. 
Host Nane. 





Enabled. 








hai 
! 
I 


IpConfig results. 2... : Passed 





o A netdiag parancs elárulja nekünk a csatolóink belső 
azonosítóit 


Ha a belső azonosító megvan, végre kiválaszthatjuk a megfele- 
lő Interface-t. Ha akarjuk, már itt a csomaggyűjtésnél is megad- 
hatunk szűrést, a Filter mező segítsé- 


d s. "és sző e eségjéglő ZSZ tri alagi] 
gével. Készíthetjük a gyűjtést rögtön 





Ma j al. gő Total 24 — (10009) 
fájlba is; ekkor a File mezőbe írjuk be EGT o hr 2 
a fájl nevét. A dialógusablak többi (TCP 19 79.259) 

fg sitátáág ját v 8 5 UDP 0 009) 
beállítása önmagáért beszél: korlá- !icwmp 0. 009) 
tozhatjuk a gyűjtendő csomagok szá-  [ 0SPF 0 009 

EÁ ÁGÁT láda 4 ázsó GRE 0 009 
mát, méretét, a gyűjtési időtartamot; — ÍNetsios — 0 0099) 
kikapcsolhatjuk a MAC címek, a háló- [FX 0 009 

hu ü date VINES 0 009 
zati címek, illetve a hálózati proto- ( other 5 6089 


koll nevének visszafejtését. 

Ha ezzel megvagyunk, kattintsunk az 
OK gombra, és már el is kezdődik a csomagok gyűjtése. Ebben az 
ablakban folyamatosan szemmel követhetjük, hogy milyen típusú 
csomagokat sikerült eddig a hálózatról összeszedni. Amikor pedig 
úgy döntöttünk, hogy elég volt, a Stop gombra kattintva bármikor 
leállíthatjuk a műveletet. 


2 
8 


A csomagok értelmezése 

Ha az elfogott csomagok listájába kattintunk, a középső és az alsó 
harmadban megjelenik a csomag visszafejtett változata. A képer- 
nyő középső harmadában a beépített protokollanalizátorok munká- 
jának eredményét látjuk (esetünkben éppen egy DNS kiszolgálótól 
visszaérkező választ; a kérdésben a www.index.hu címét firtattuk): 


BFrame 2 (163 on wire, 163 captured) 
Bethernet II 
Binternet Protocol, src Addr: legba.tvnet.hu (195.38.96. 
Eluser Datagram Protocol, Src Port: domain (53), Ost Port: 
Eloomain Name System (response) 
Transactton ID: 0x00c6 
BFlags: 0x8180 (standard guery response, No error) 
Guestions: 1 
Answer RRS: 1 
Authority RRs: 2 
Additional RRs: 2 
Baveries 
B www. index.hu: type A, class inet 
B answers 
EJ www. index.hu: type A, class inet, addr 217.20.134.241 
Bauthoritative nameservers 
Baddíttonal records 
E ns.index.hu: type A, class inet, addr 195.56.65.172 
Bns.inventra.hu: type A, class inet, addr 194.,88.58.14 





26 (1026) 


ost addr: twilighr.falatcax.hu 





CA 


o Néhány a rendelkezésre álló protokollok közül 


Szűrés 

Ha a megjelenített csomagok tömegét szűrni szeretnénk, kat- 
tintsunk az ablak alján található Filter gombra! (A szűrőparan- 
csot - ami egyébként nem más, mint egy szöveges érték - kézzel 
is begépelhetnénk, de az Ethereal segít nekünk azt felépíteni). 





CEZ 


Relation 





Source Port 





Source or Destination Port 
Segyence number 

Next segvence number 
Acknowedgement number 

Header Length 

Flags 

Congeston Window Reduced (CWR) 
ECN-Echo 

Vigent 

Acknowedgment 

Push 

Reset 

Syn 


FEET 2 , 


5 A szűrőparancs összekattintgatható egérrel is 


















Ha a szűrőnk túl szigorú lett, és a listából minden el- 
tűnik, a Reset gomb segítségével visszaállíthatjuk az 
alapértelmezést. A szűrők szintaxisának teljes, részle- 
tes leírását megtaláljuk a program dokumentác 





Jobbktlikk egy csomagon... 
... és elénk tárul az Ethereal igazi világa. Kattintsunk 
jobb gombbal egy csomagra: 





5 Egy DNS válasz belső lelkivilága 


A hierarchia tükrözi a hálózati csomag belső felépítését: a hie- 
rarchia egyes pontjain böngészhetjük az Ethernet keret, az IP 
csomag, az UPD fejléc vagy - mint ábránkon - a DNS válasz tar- 
talmát és értelmezését. Az Ethereal több mint 250 beépített 
protokollértelmezőt tartalmaz, közöttük sok olyat, amit a Micro- 
soft Network Monitor nem: ilyen pl. a Kerberos, vagy mondjuk a 
Ouake :-); és persze nem esik kétségbe akkor sem, ha mondjuk 
dinamikus DNS kéréseket, vagy IPSec csomagokat kell visszafej- 
tenie! A protokollanalizátorokat egyenként ki- és bekapcsolhat- 
juk ha a Edit menü Protocolls... parancsára kattintunk: 





working with 


windows / 


a 
Fi 





Edít  Capture Display Tools 





Value (unsigned, 2 bytes) 













Na. . [Time Source Destination Protocol. [dnfo 






























3.087922 www. index. hu twilághr. falatr Follow TCP Stream 
12 3.113023 www. index.hu twilight.falatr Decode As. 
13 3.116160 www. index.hu twilight.falatr 
14 3.116452 twilight.falatrax.hu www.index.hu Display Filters. 
15 3.143551 www. index.hu Twilight. falarr 
16 3.143923 twiltoht.falatrax.hu www.index.hu (fedte ree 
17 3.145327 www. index.hu twilight. falatr Match 
18 3.147306 www. index. hu " twilight.falatr prepare 
19 3.147588 twilight.falatrax.hu www. index.hu 
20 3.169820 www. index.hu Twilight. falatr Colorize Display. 
21 3.170221 twilight.falatrax.hu www. index.hú pint 
22 3.173783 www. index.hu twilight.falatr F9Nt 





23 3.185879 www. index.hu rwiliaht.falatr Print Packet 





o ssel StEt ER ENNE KSS NN ERNNEGÉGÉE 


(B Frame 10 (394 on wire, 394 captured) 


5 A csomagokon végrehajtható parancsok 


EMUZ. MV. 


7 3.036392 twilight.falatrax.hu www. index.hu TCP 1296 5 hrtp 
8 3.056078 www. index. hu twilight.falatrax.hu TCP http 5 1296 
9 3.056215 twilight.falatrax.hu www. index. hu TP 1296 5 http 
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A , Follow TCP Stream" egy nagyon ügyes eszköz: össze- 
válogatja és megjeleníti az adott csomag által kijelölt 
kommunikációs csatorna teljes tartalmát. Példánkban a 
http://www.index.hu webkiszolgálónak elküldött kérést 
tartalmazó csomagra kattintottunk, és eredményként vissza- 
kaptunk a weboldal teljes tartalmának forráskódját, hibamentesen 
összerakva, a különböző irányú kommunikációt különböző színekkel 
jelölve (bár ez nem biztos hogy az újságban is látszani fog): 


ETL E 





accept: image/gif, image/x-xbítmap, image/jpeg, image/pjpeg. applicatfon/vnd.ms-excel, apa 
leste FönASE AS -BGVOTÁGTAE applicatton/msword, "/o 
u; geo. 0 






gz1e. defiateg 
user-agent: a/4.0 (compatible; MSIE 6.0; windows NT 5.1; 9312461)o 
Host: wew. index. hug 

konnection: Keep-aliven 


ő 
HTTP/1.1 200 OKO 

Date: Sun, 21 Apr 2002 16:30:45 GMTO 
Server: apache/1.3.23 (Unix) PHP/4.1.20 
JEache-control: max-ager3000 

jexpires: Sun, 21 Apr 2002 16:35:45 GMTO 
keep-alive: tímeouts2, maxs10000 
Onnection: Keep-aljven 
Transfer-Encoding: chunkedo 
kontent-rype: text/htm1o 


c 
5590 

jet-n head start ——50 

e1-- FEJLEC INCLUDE START —s 
ehtmtz 

head 


[meta http-eguverefresh contents17405 
etitlesíndexeztít les 


e! adengine § webaudit too] --s 
c1-- fndexadengíne header version? //--s 

jeseript languages" Javascrípt" types text/javascript"s 

var indexadengíneui s Math.round(Math.random()"10000000); 

var same s indexadengíneut; / 


Entire conversation (120649 bytes) A DASCII s EBCDIC . Hex Dump Print) Save Asj Close 


5 Egy TCP csatorna , összerakott" forgalma 








ET 
CreateDir ] Delete File [ Rename File 


dséelj 





A 
images.tmpl 

Program FilesV 

Projectst 

RECYCLERV 

System Volume Informationt 


, j 


1 Save only packets currently being displayed 


1Save only marked packets 


File type: libpcap (tepdump, Ethereal, etc.) ű 


Selection: NAA 
N 


OK Cancel 


r8 


0 A mentőpanel.. ha kitapasztaljuk, hogy 
működik, már nincs gond 


Ha viszont megszoktuk egymást, minden valószínűség 
szerint használni is sikerül majd. Ha csak a szűrőnkön 
fennmaradt csomagokat szeretnénk menteni, akkor vá- 
lasszuk a , Save only packets currently being displayed" 
opciót. Ugyanez igaz a kijelölt csomagokra is (ha van- 
nak): ilyenkor a ,Show only marked packets" az érdekes. 


Analízis és összefoglaló információk 


Az ábrán jól látható és szétválasztható a különböző irányú for- 
galom, sőt, akár az oldal teljes forráskódja is; nem kell többé a 
hexadecimális panelen vakoskodnunk! 

A következő parancs a , Decode As".... A beépített protokollana- 
lizátorok ethernet kerettípus (ethertype) , IP protokollazonosító, 
illetve TCP/UDP portcím alapján ,harapnak" rá a hálózati forga- 
lomra. (A TCP 80-as port például így ,, lesz" HTTP). Ha viszont mi 
azt szeretnénk, hogy az Ethereal a 81-es port forgalmát is HTTP 
forgalomként kezelje, válasszuk ki a csomagot, és a Decode 
As... csomag paneljében állítsuk be ezt: 


B Frame 


(A Fthereal: Derode As 


Úink [Network Transport ] 


TCP destination (81) — [ ports) as 


7 Do not decode 


oMostantól a TCP 81-es port is HTTP 


A további menüparancsok segítségével kijelölhetjük a csomago- 
kat, figyelmeztető színekkel láthatunk el bizonyos típusú cso- 
magokat, vagy éppen kinyomtathatjuk azokat (bár a nyomtatás 
még nem igazán kiforrott). 


Fájlok betöltése és kimentése 

Az Ethereal számos fájlformátumot ismer. Alapértelmezett for- 
mátuma a libpcap/tcpdump formátum, de kezeli (olvasni és men- 
teni is képes) többek között a Microsoft Network Monitor formá- 
tumát is (!). A formátumot egyébként csak mentéskor kell beál- 
lítani, beolvasáskor az Ethereal automatikusan felismeri a hasz- 
nált formátumot. A kimentő/betöltő panellel bánjunk óvatosan, 
mert úgy viselkedik, mintha egy kisdiák írta volna tíz éve Pas- 
calban, nyári gyakorlaton... 


working with 


A Ethemet 
B intemet Protocol 100004 827 


windows / 


A Tools menüben további szolgáltatásokat találunk: a Plugins... 
parancs hatására láthatjuk a telepített kiegészítő DLL-eket, a 
TCP Stream Analysis néhány grafikonnal kényeztet minket, a 
Protocol Hierarchy Statistics pedig az elfogott hálózati forgalom 
protokolleloszlását mutatja: 


AA Ethereal: Protocol Hierarchy Statistics 


Protocol Hierarchy Statistics 
- [protocol 96 Packets] Packets] Bytes] End Packete] End Bytes] 





100.0096 827 
100/0094 827 


B User Datagram Protocol 20009 235 
Domain Name Semce 200095 235 
Internet Control Message Protocol 80.009 592 


Close 





5 Egy ping parancs protokolleloszlása: két DNS (egy kérdés, 
egy válasz), és nyolc ICMP (négy kérés, négy válasz) csomag 


Fülöp Miklós 
mick 2netacademia.net 


A cikkben szereplő URL-ek: k SEERS 


[1] http://www.ethereal.com 
[2] http://winpcap.polito.it/install/default.htm. 
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(I. rész) 


Magyarországon is egyre több vállalat jut arra a felismerésre, hogy a heterogén infrastruktúra 
hosszú távú örökség is lehet - az egységesítés fontos, ám költséges és technikai kihívásokkal 
teli folyamat. Metacímtár kialakításával rövid távon is égető problémákat oldhatunk meg, 
miközben megtesszük a kezdőlépést hosszú távú egységes címtárstratégiánk megvalósítása felé. 


A központi címtár problémája 

Azt hiszem mindenki számára ismerős a magyar (de valószínűleg 
nemzetközileg is gyakori) helyzetkép: a vállalat rengeteg címtárral 
vagy csak egyszerű felhasználói adatbázissal rendelkezik. Az alapok 
áltálában mindenhol megvannak, létezik egy széles körben használt 
hálózati címtár (Network Operation System, NOS Directory — felhasz- 
nálók, kiszolgálók, munkaállomások adatainak tárolására — ezt a funk- 
ciót tipikusan az NT4 tartományi modell, Windows 2000 Active 
Directory vagy Novell NDS tölti be). A hálózati címtár jó esetben nagy- 
vállalati címtárként is használható (Enterprise Directory), ilyen pl. az 
Active Directory, amely alkalmazások (Exchange2000, ISA2OOO, 
stb...) adatait is tárolhatja. Elvben és technikailag arra kellene töre- 
kednünk, hogy minden vállalati alkalmazás ezt az egyetlen, közpon- 


flow-alap vezénylése több címtárat érintő változtatásoknál stb. 

A kép így egyre árnyaltabb lesz. Mielőtt konkrétan tárgyalnánk a Mic- 
rosoft Metadirectory Services metacímtár megoldásának működését 
(melyre csak a következő számban kerül sor), most elvben tekintjük 
át, hogy mik is pontosan az elvárásaink egy általános metacímtár 
rendszerrel szemben, mik a gondok amiket egy metacímtárnak meg 
kell oldania - azaz az ún. identitáskezelési problémakört vizsgáljuk meg. 


Identitáskezelés 

Identitás alatt a személyekről, alkalmazásokról és erőforrásokról 
meglévő, címtárakban és adatbázisokban elszórtan tárolt informá- 
cióinkat értjük. Egy személy identitásadata lehet például a neve, e- 
mail címe, fizetése vagy beosztása. Az alkalmazások identitásadatai 


I 


S3DTAJ3S ÁJOJJDBJIPRJöW 3JOSOJDTW / 


ti vállalati címtárat használja (jó esetben az Active Directoryt) — ám például az alkalmazást kiszolgáló szerverek hálózati címei vagy az k 
szembe kell néznünk a tényekkel és a realitásokkal: korábbi beszer- " egyes alkalmazások által publikált szolgáltatások köre. A hálózati 2 
zésekből, saját fejlesztésekből vagy éppen a külső gyártó stratégiá- erőforrásoknak - pl. nyomtatóknak - szintén vannak identitásadatai úa 
jából fakadóan a vállalat egyedi címtárszigetekből épül fel. Hosszú- — - például a helyük, vagy az általuk támogatott nyomtatási módok. za 
távon kijelölhető ugyan egyetlen címtár központinak (pl. az Active e 
v 4 áá ő: éöaekűl 4444 alá 4.sé Munkaállomások B 

Directory) , ám a régi, egyedi címtárak átírása, lecserélése a stratégiá- e Beállítások / kössük 

Al fé tl zé § a e Hálózati Ti Bi I Kiszolgálók 
nak megfelelően meglehetősen költséges - olykor nem is lehetséges paraméterek ( ] l a . Szolgáltatások 

5 Házírend kuzzzzttllii "5  Beállításol 


- előfordulhat, hogy a külső gyártó nem támogatja az általunk pre- 
ferált címtárat, és nincs más megoldás a piacon. Ez gyakori eset a 
speciális, kis részterületre összpontosító üzleti alkalmazások esetén 


Felhasználók 
2 Fiók (account) 
2 Jogosultságok 
7 Profilok 

2 Házirend 


L a " Hálózati 
íj paraméterek 
MEL e Nyomtatók 


A . Fájlmegosztások 
3 ML 
1— Hálózati eszközök 


9 Házirend 
ML - Konfiguráció 
E ÉP 2 005 házirend 





tens adatokat jelenti. Egyedi címtárszigetek között ezt a konziszten- 
ciát az adatok szinkronizációjával is megvalósíthatjuk. Két vagy há- 
rom címtár szinkronizációja még megoldható ún. konnektorok, 
szinkronizációs felületek segítségével, e felett azonban már bonyo- 
lult, nehezen kézben tartható topológiát kapnánk a vezetékek be- 
kötögetésével. Logikus tehát egy csillagtopológiában gondolkoz- 
nunk, azaz mégiscsak beültetni valamit középre, egy szinkronizációs 
útvonalválasztót, router-t, ami intelligensen vezényli a szinkronizá- 
ciós folyamatokat. Ha a vezénylés szó ismerős lenne a BizTalk szer- 
ver terminológiából, valljuk be: valójában itt egy köztes rétegről, 
üzleti logikát tartalmazó speciális middleware-ről van szó. Az identitáskezelési problémakör 

A szinkronizáció irányításával ugyanis valójában leegyszerűsítettük — Az identitásadatok változatossága és tárolási helyük sokfélesége 
a feladatot - egy ilyen útvonalválasztó még nem nevezhető meta- több problémát vet fel: 

címtárnak. A metacímtár valóban tartalmazza a fent említett üzle- "5 Nem minden identitásinformáció érhető el címtárakon 

ti logikát, és - a szinkronizáción keresztül - számos más gondunk- (pl. LDAP-on, Lightweight Directory Access Protocolon) keresztül 
ra is orvosságot jelenthet: egypontos bejelentkezés (single-sign- - sok rendszer saját objektumainak identitásadatai kizárólag 
on), központi jogosultságkezelés, automatizált folyamatok work- programozói felületeken (API-kon) keresztül érhetők el. 


(pl. speciális banki szoftverek, értékpapír-kezelés, devizakezelés, stb. ). sa 
Az egységes központi címtár sokunk számára elsősorban a konzisz- da ú 
nun — ú Identitás 
Alkalmazások 


f 


" Biztonsági beállítások 


2 Szerverkonfiguráció 
e Single Sign-On 
§ Alk. specifikus 


információk 














Tűzfalak 
§ Konfiguráció 
9 VPN beállítások 
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eMail kiszolgálók 
s Postafiókadatok 
5 Levelezési listák 





5 Az identitáskezelési drámakör 


Be 


wörkinú with vindüws /7 20082. Ú4. 
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"Az identitásadatok gyakran több helyen, több pél- 
dányban fordulnak elő, a különböző változatok 
gyakran eltérnek egymástól, ami az idő előreha- 
ladtával csak rosszabbodik. 
Általában nincs egyetlen hely, ahol az adminiszt- 
rátorok vagy az alkalmazások a konszolidált ada- 
tokat (az ún. join-t) elérhetik. 
"PI Minden egyes új alkalmazás bevezetésével az iden- 
j titásadatok újabb tára jelenik meg a rendszerben. 
Rendszerezve ezeket a jelenségeket egy identitáskezelő rendszerrel 
kapcsolatban az alábbi elvárások jelennek meg általában: 


Közös ,,telefonkönyv"/felhasználói adatbázis. Több (leány)válla- 
lat, szervezeti egység telefonkönyvének, postafiókadatainak szinkro- 
nizációja, mely lehetővé teszi, hogy a különálló (leány) vállalatok dol- 
gozóinak névjegy-információi a munkatársak rendelkezésére álljanak. 
Felvétel/távozás támogatása. A frissen felvett dolgozó adatainak 
eljuttatása az érintett rendszerekbe segít abban, hogy az illető mun- 
kafeltételei gyorsan teljesüljenek. Ugyanennek gyors, fordított irányú 
végrehajtása szükséges akkor, amikor az illető a vállalattól távozik. 
E-commerce alkalmazások. Vállalati szintű indentitásadatok (pl. di- 
gitális aláírások) szinkronizációja beszállítókkal és extranet felhasz- 
nálókkal vagy más, a tűzfalon kívül található címtárakkal. 

Egyszeri belépés kezdeményezések (Single Sign-On) . Felhaszná- 
lói nevek, jelszavak és jogosultságok megosztása platformok és al- 
kalmazások között, melyek esetleg eltérő hozzáféréskezelési és tit- 
kosítási technikákat alkalmaznak. 


Követelmények 

Az egyetlen, központi címtár bevezetésére irányuló erőfeszítések 

rendszerint kudarcot vallanak az alábbi egyszerű problémák vala- 

melyike következtében: 

"8 Sok alkalmazás nem módosítható úgy, hogy a közös címtá- 
rat használja. 

"0 Sok esetben az alkalmazásnak jó (pl. adatbiztonsági) oka van 
arra, hogy ezen adatokat saját formátumában tárolja. 

"0 Az egyébként lehetséges technológiai megoldások bevezetését 
gyakran politikai megfontolások akadályozzák. Az egyes önálló 
szervezeti egységek, osztályok nem szívesen engedik át a fel- 
ügyeletet saját címtáradataik felett egy központi szervezetnek. 

A fentiek alapján valószínű, hogy az identitásadatokat továbbra is 

sok helyen, különböző formákban fogjuk tárolni, fel kell tehát ké- 

szülnünk arra, hogy ezen szolgáltatások együttműködését biztosít- 
suk. A fenti feltételezést elfogadva a megoldásnak gondoskodnia 
kell a következőkről: 

"1 Kapcsolódás lehetőségének megteremtése nagyszámú külön- 
böző rendszerhez. 

"0 Az identitásadatok különböző rendszerek közti áramlásának 
kezelése. 

"2 Az adatok konzisztenciájának biztosítása a teljes identitáske- 
zelő rendszerre vonatkozóan. 

A következőkben a fent említett szempontokat tárgyaljuk. 


Kapcsolódási lehetőségek (Connectivity) 

A kapcsolódási lehetőségekkel szemben támasztott követelmény egy- 
szerű: minél több címtárhoz, adatbázishoz és alkalmazáshoz képes 
kapcsolódni a rendszer, annál nagyobb értéket képvisel alkalmazója 
számára. Ha valamely információ nem áll rendelkezésre az egyik cím- 
tárban, esetleg elérhető egy másikban. 

Az identitáskezelő megoldás akkor képes kapcsolódni valamely 
adattárhoz, ha képes követni az ott lezajlott változásokat, új ele- 
meket felvenni, meglévőket törölni, tulajdonságait megváltoztatni. 
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Az átfogó megoldás érdekében a megoldásnak képesnek kell lennie 

az alábbi adatforrások kezelésére: 

8 Szabványokon alapuló, LDAP V3-on keresztül elérhető címtárak 
(Active Directory, Novell NDS, Netscape Directory Services, stb.), 

0 Elterjedt levelezőrendszerek és nem-LDAP címtárszolgáltatások 
(Exchange 5.5, Lotus Notes, egyedi fejlesztésű céges tele- 
fonkönyv, stb.), 

0 Integrált vállalatirányítási rendszerek (ERP, Enterprise Resource 
Planning - SAP, JDEdwards, Oracle Financials, Peoplesoft, 
Scala, stb.), 

21 Adatbázisok, valamely elterjedt lekérdezőfelületen keresztül 
(pl. SOL, ODBC, OLE-DB). 

"2 Olyan alkalmazások, melyek kizárólag programozói felületeken 
(Application Programming Interfaces, API) keresztül érhetők el. 
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5 A kapcsolattal szemben támasztott követelmények 


Adatáramlás (Information Management Flow) 

A rendszer által megvalósított adatáramlásnak támogatnia kell az 
identitásadatok különböző adattárak közti áramlását, képesnek kell 
tehát lennie az identitásadatok változásának detektálására és a mó- 
dosulások továbbítására más rendszerek felé, a különböző adattárak 
adatainak egyetlen, a vállalat teljes képét tartalmazó metacímtárba 
való összegyűjtésére, egymással összefüggő adatok nyomon kö- 
vetésére, miközben azok helye változhat az egyes adattárakon belül. 


Változtatások követése (Change Event Processing) 

A változás eseménye akkor következik be, amikor egy adminiszt- 
rátor, felhasználó vagy alkalmazás valamely adattárban identitás- 
adatot hoz létre, töröl vagy módosít. Az identitáskezelő megoldá- 
soknak képeseknek kell lenniük ezen változások észlelésére, a 
szükséges adatformátum-transzformációkra, majd valamennyi 
adattár megfelelő módosítására annak érdekében, hogy azok kon- 
zisztens állapotban maradjanak. 
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5 Változtatások követése 
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Ha például a személyügyi alkalmazásban új dolgozót rögzítenek, a 
dolgozó által használt alkalmazások adattárait szintén módosítani 
kell - ezt szemlélteti az előző ábra. 


Aggregációs képességek 

Amíg az identitásinformáció különböző rendszerekben elszórtan 
található, az ezt az információt egyesítő címtárak komoly értéket 
képviselnek. Magát a metacímtár-koncepciót és kifejezést a 
Burton Group használta először. Szintén ők alkalmazták a join ki- 
fejezést a vállalat aggregált identitásadatainak reprezentációjára. 
Egy metacímtár használatával az alkalmazások az információ szé- 
les körét érhetik el egy helyen, egyetlen hozzáférési módszerrel. A 
metacímtárak az adatok ideiglenes tárolásával és indexelésével (il- 
letve particionálásával és replikálásával) a teljesítmény növelésére 
is képesek lehetnek: a lekérdezőnek nem kell közvetlenül az adat- 
forráshoz fordulnia, mely esetleg egy WAN vonal túloldalán talál- 
ható. Az aggregációs mechanizmusnak képesnek kell lenne az in- 
formáció összegyűjtésére számos különböző forrásból, pl. címtá- 
rakból, adatbázisokból és alkalmazásokból. 
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5 Aggregáció a metacímtárban 


Az összefüggő információt csoportosítani kell tudnia, függetlenül 
annak származási helyétől és tárolási módjától (lásd. az illusztrációt 
az előző ábrán, ahol egyetlen felhasználó a különböző rendszerekben 
különböző azonosítókkal rendelkezik). Az információt vissza kell 
tudnia áramoltatni a forrásrendszerekbe a metacímtárban elvégzett 
módosítások (az üzleti logika lefuttatása) után. 


Kapcsolódó objektumok követése (Related Object Tracking) 

Az identitáskezelő rendszer bevezetésekor a rendszernek támogat- 
nia kell az összefüggő objektumok azonosítását (pl. hogy Kovács 
Eugén, ekovacs és kovacse egy és ugyanaz a személy) . Ezután (ahogy 
az a következő ábrán látható) a rendszernek követnie kell ezeket az 
összefüggéseket az identitásadatok esetleges átszervezése ellenére 
is. A megoldás nem veszítheti el egy dolgozó nyomát akkor sem, ha 
az illető a pénzügyről a kereskedelembe, és ezáltal valamely címtár- 
ban egyik fából a másikba kerül. 
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5 Kapcsolódó objektumok követése 
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Integritáskezelés (Integrity Management) 

Az integritáskezelés feladata annak biztosítása, hogy 
az identitásinformáció az esetleges módosítások elle- 
nére se váljon hibássá vagy inkonzisztenssé a különböző 
rendszerekben. Az integritáskezelésnek kezelnie kell az ada- 

tok tulajdonosi (ownership) viszonyait, megfelelő szabályok alap- 
ján fel kell oldania a több rendszerbeli együttes módosítás közben 
esetlegesen előforduló ütközéseket (hibakezelés), meg kell őriznie 
az identitásadatok közti hivatkozások helyességét. A következők- 
ben ezt a három feladatot részletesebben is bemutatjuk. 


Alkalmazások Alkalmazások 
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eMail: Alárendelt 
Szoba: Egyenrangú 
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eMail: Elsődleges 
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5 Birtoklási relációk kezelése 


Birtoklás (Ownership) 

Az identitáskezelő-rendszerek egyik fontos jellemzője az egyes 
rendszerek és a bennük tárolt adatok birtoklási kapcsolatainak 
felismerése. 

Példaképpen: a legtöbb vállalatnál az alkalmazott postafiókjának 
címét a levelezőalkalmazás birtokolja. Ezzel egyidejűleg a személy- 
ügyi rendszer szintén tárolhat ilyen információt. Identitáskezelő- 
rendszer alkalmazása nélkül mindkét birtoklási szabály érvényre jut- 
hat, hiszen nincs harmadik alkalmazás, mely a két, eltérő rendszer 
azonos jellegű adatát szinkronban tartaná. 

A birtoklás jellege attribútumszintű kell legyen: a fenti esetben a 
postafiókcím a levelezőrendszer, a munkahelyi vezető attribútum 
viszont a személyügyi rendszer birtokában kell legyen. Nem állhat 
mindkettő a személyügyi rendszer fennhatósága alatt, hiszen a 
postafiók címének megváltoztatása a levelezőrendszer tudta nélkül 
komoly gondokat okozna. Ugyanakkor lehetnek olyan attribútumok 
(pl. szobaszám) , melyek mindkét rendszerből módosíthatóak. 

A követelmény tehát, hogy a rendszerben attribútumszinten 
megadhatók legyenek a birtoklási viszonyok. Amennyiben egy mó- 
dosítás összhangban van e birtoklási szabályokkal, azt a többi 
rendszer felé továbbengedhetjük, ha nincs, a továbbítást blokkol- 
juk, vagy éppen visszafordítjuk. Ha például a fenti esetben a beosz- 
totti viszonyt a személyügyi rendszer tudta nélkül a levelezőrend- 
szerben átállítjuk, akkor a rendszernek képesnek kell lennie ezt 
visszaállítani a személyügyi rendszerben szereplő értékre. 


Hibakezelés (Failure Management) 

A változások több adattárba való továbbításának lehetősége az 
identitáskezelő-technológiákkal szemben támasztott alapvető 
követelmény. Az egyidejűleg elvégzendő több módosítás miatt 
azonban fennáll annak a lehetősége, hogy közülük valamelyik 
nem sikeres, és így sérül az adatok konzisztenciája, ahogy az az 
alábbi ábrán látható. 

Ha például egy személy beosztása, fizetése és költségkerete egy- 
szerre kell, hogy módosuljon, de a metacímtár nem képes valameny- 
nyi alkalmazásban módosítani a beosztást, az identitásinformációk 
inkonzisztens állapotba kerülnek, melynek elhárítása általában sze- 
mélyes vizsgálatot és beavatkozást igényel. 
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5 Hibakezelés és a hivatkozási integritás fenntartása 


Az adatbázisrendszerek ezt a problémát általában tranzakciók segít- 
ségével kezelik, melyek biztosítják, hogy a módosításnak vagy vala- 
mennyi művelete sikeresen végrehajtódik, vagy egyetlen egy sem. 
Sajnos azonban a legtöbb címtár- és alkalmazásprogramozói felület 
nem támogatja a tranzakciók kezelését, az identitáskezelő rendsze- 
reknek tehát más megoldást kell választaniuk: általában naplózáson 
alapuló, ,kívánatos állapot" mechanizmusokat, melyek addig pró- 
bálják a változást érvényre juttatni, amíg az sikeres nem lesz. 


Hivatkozási integritás (Referential Integrity) 

A másik, adatbázisrendszerekkel közös probléma a több adattár kö- 
zött fennálló hivatkozási integritás biztosítása. Hivatkozási integri- 
tásnak nevezzük azon szabályok összességét, melyeket bizonyos, 
különböző helyen tárolt adatelemek közti összefüggéseknek ki kell 
elégíteniük. Az identitáskezelő-rendszereknek például biztosítaniuk 
kell azt, hogy egy alkalmazottnak a pénzügyi rendszerben tárolt 
költségkerete megfeleljen a személyügyi rendszerben tárolt beosz- 
tásának. Az adatbáziskezelő rendszerek e probléma megoldására ún. 
triggereket és tárolt eljárásokat biztosítanak, melyekkel a programo- 
zó vagy az adatbázis adminisztrátora bizonyos adatelemek megvál- 
tozása esetén valamely üzleti szabályt érvényesíthet. A mai címtá- 
rak nem tartalmaznak ilyen szolgáltatásokat, az identitáskezelő 
rendszereknek tehát biztosítaniuk kell olyan szolgáltatásokat, me- 
lyek a hivatkozási integritást sértő változtatásokat visszautasítják. 
Mindezeknek az elvárásoknak összességében tehát csak egy már fent 
is említett metacímtár rendszer tud megfelelni. 


A metacímtár megoldás 

A metacímtár lehetővé teszi az elszórtan, szigetekben létező, vál- 
tozatos adatformátumokat alkalmazó címtárak integrációját, és így 
az identitásadatok elsődleges forrásává válik a vállalaton belül. A 
metacímtár az eltérő forrásokból származó attribútumokkal rendel- 
kező objektumok egyesített képét valósítja meg. Ez az integráció 
lehetővé teszi az adminisztrációs költségek csökkentését, a dupli- 
kációk megszüntetését, az eltérések csökkentését, és az identitás- 
adatok széles körben való elérhetőségét. A metacímtár elég rugal- 
mas, hogy bármely szervezet felépítéséhez, politikai viszonyaihoz, 
üzemeltetési eljárásaihoz alkalmazkodjon, és elég dinamikus, hogy 
a szervezet változásával együtt változzon. 


Források 

A metacímtár adatait a szervezet más, a metacímtárhoz kapcsolt 
adat- és címtáraiból szerzi. Szinte minden levelező-, adatbázis- és 
címtáralkalmazás képes tartalmát valamilyen formában exportálni. 
A metacímtár ezen adatokat fájlcsere, e-mail üzenet, vagy valami- 
lyen online kapcsolat révén képes fogadni. Természetesen manuá- 
lis úton is bevihető információ a rendszerbe. 
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Tartalom 

Általánosan elterjedt nézet, hogy a címtárak csak a személyek iden- 

titásadatait (pl. e-mail címét) kezelik; a valóságban a lehetőségek 

ennél sokkal tágabbak: a metacímtár sok más, valós világbéli ob- 

jektumról képes információt tárolni, ilyenek pl. 

"0 fizikai objektumok (pl. személyek vagy számítógépek) , 

"0 fogalmak (pl. szervezetek vagy osztályok), 

"0 földrajzi objektumok (pl. országok vagy városok), 

"0 digitális formában létező objektumok (pl. online megtekintésre 
szánt dokumentumok). 

A metacímtár egyetlen követelménye ezen adatokkal szemben, 

hogy azok valamiféle hierarchiába szervezhetők legyenek. A pél- 

da kedvéért egy személy tagja egy osztálynak, amely része egy 

szervezetnek, amely valamilyen Internet tartományban vagy or- 

szágban található. Egy multinacionális szervezetben egy alkal- 

mazott tagja lehet valamely üzletágnak, amely valamely ország- 

ban a szervezeti fába illeszkedik. 

A , személy" nem feltétlenül a hierarchia legalsó szintje. Elképzelhe- 

tő például, hogy az egyes alkalmazottak birtokában lévő dokumen- 

tumok vagy eszközök a személy alá rendelt szinten kapnak helyet. 


Rendszerfelügyelet 

A metacímtár tartalmának és biztonsági kérdéseinek kezelése lehet 
központosított, elosztott vagy a kettőnek valamilyen kombinációja. 
Elképzelhető olyan megoldás, melyben a változások bizonyos be- 
jegyzések esetében kizárólag a forrásrendszerekben, más bejegyzé- 
sek esetében viszont csak a metacímtárban kezdeményezhetők. A 
metacímtár bizonyos tartományait más és más adminisztrátorok ke- 
zelhetik, ez pedig vonatkozik az egyes elemekre éppúgy, mint bizo- 
nyos attribútumaik halmazára. Elképzelhető például, hogy az egyes 
felhasználók saját telefonszámaikat, címüket maguk szerkeszthetik. 
A metacímtár tehát nem kényszerít a szervezetre semmilyen 
rendszerfelügyeleti modellt, hanem lehetővé teszi olyan címtár 
létrehozását, mely alkalmazkodik a szervezet valós felépítésé- 


Microsoft Metadirectory Services 

A fentieket olvasva számos fogalom, működési mód már ismerős le- 
hetett az Active Directory ismereteinkből. Az Active Directory nem 
metacímtár, csak nagyvállalati címtár, annak ellenére, hogy a fen- 
ti elvárások jó részét teljesíti (pl. tartalmaz konnektorokat bizonyos 
adatforrásokhoz). A Microsoft metacímtár megoldása az MMS 
(Metadirectory Services) , de a két termék egyre inkább közelebb ke- 
rül egymáshoz, így Active Directory tudásunkat tovább építve érde- 
mes megismerkednünk az MMS lehetőségeivel is. Erre részletesen a 
tech.net magazin következő számában kerítünk majd sort. 


A cikk az alábbi Microsoft műszaki tanulmány alapján készült: 
Microsoft Metadirectory Services Concepts and Architecture 
http://www.microsoft.com/windows2000/techinfo/howitworks/ 
activedirectory /MMSintro.asp 
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IP Multicast 


Unicast és Broadcast 


Az IP Multicast az a hálózati forgalomtípus, mely a Unicast és Broadcast 
között helyezkedik el félúton, s amely szép új jövőnk alapja. 

E nélkül ugyanis nehezen lehetne elképzelni Pirx kapitány kalandjait, 
hisz ha nincs Multicast, nincs sokrésztvevős videokonferencia 


sem itt a Földön, sem a jövőben, az űrben. 


Unicast és Broadcast 

Elsőként vizsgáljuk meg, hogyan is zajlik az a két hálózati for- 
galomtípus, amelyeket mindannyian ismerünk: a Unicast és a 
Broadcast. A Broadcast az egyszerűbb a kettő közül: egy adott 
hálózati szegmensen egy gép mindenkihez szól. Például amikor 
egy Windows 95/98/2000/XP indul, úgynevezett Browse Anno- 
uncement Broadcast üzenettel adja tudtára az adott szegmens 
összes gépének, hogy ő nem más, mint NKARALABE, és nála fut 
mind a Workstation, mind a Server szolgáltatás. Az operációs 
rendszerek indításának hálózati forgalmáról szóló cikkem a 
tech.net magazin májusi számában bitszinten elemzi ezt a for- 
galomtípust. Ez a címzésmód Ethernet-nyelvre lefordítva annyit 
jelent, hogy míg a csomag feladója egyetlen gép, addig címzett- 
je az összes létező masina, beleértve az Ethernet kártyával fel- 
szerelt nyomtatókat, hűtőgépeket és kólaautomatákat is. Bit- 
szinten a dolog úgy néz ki, hogy míg az Ethernet keret feladó 
mezője valóban a feladó címével (MAC Address, például 00-AO- 
CC-CO-71-18) van kitöltve, addig a címzett címének minden bit- 
je csupa egyes (FF-FF-FF-FF-FF-FF), melyre minden gép figyel. 
Ebből is látszik, hogy a sok-sok broadcast miért nem kívánatos 
a hálózatokon: minden egyes gépnek foglalkoznia kell vele még 
akkor is, ha valójában nem tud mit kezdeni vele. Hogy még egy 
szemléletes példával éljek a Broadcast címzésmód ellen, vajon 
mit szól a kólaautomata a hálózat sok-sok gépének DHCP cím- 
kéréséhez? Ugyanis a címkérés kezdeti csomagja (DHCP Disco- 
ver) Broadcast címzésű (hisz a kérelmező gép nem is használhat 
mást: fogalma sincs, ki a DHCP Server) , így az minden gépen fel- 
dolgozásra kerül, zörög a winchester, pereg az órajel, s a végén 
az üzenet minden normál gépen kikukázódik - egyedül a valódi 
DHCP Server nem dogozott feleslegesen. 

A Broadcast címzés használata sokszor erőforráspazarlással jár, 
mert válogatás nélkül minden gép megkapja a csomagot. 


A Unicast címzésről a következő állapítható meg: mind a feladó, 
mind a címzett MAC Addresse helyesen van kitöltve az Ethernet 
keretben, így csak és kizárólag a címzett gép dolgozza fel a ben- 
ne rejlő adatokat - kivéve talán Hacker Henryt, aki egy úgyneve- 
zett Snifferrel minden hálózati forgalmat elkap a szegmensen, füg- 
getlenül attól, hogy az neki szólt-e vagy sem (kötekedő barátaim: 
hubot feltételezve) . Erre azért lenne képes Henry, mert az Ethernet 
üzenetszórásos jellege miatt (amin csak egy switch üzembe helye- 
zése változtat, s az sem elvileg, hanem kizárólag gyakorlatilag szün- 
tetni meg az üzenetszórást) még Unicast címzés esetén is eljut a 
csomag mindenhova - viszont ebben az esetben már a hálózati 
kártyák elhajítják az érdektelen csomagokat, nem kell megvárni, 
míg az operációs rendszer kimondja a halálos ítéletet. 
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5 A szaggatott vonal mutatja a feldolgozott Unicast forgalmat. 
A többi gép hálókártyája eldobja a csomagot — 
bár oda is megérkezik! 


A Unicast címzés hatékonysága is megkérdőjelezhető, ha egyszer- 
re nem egy gép lenne a címzett - de nem is mind! Szép példája 
a Unicast sávszélességpazarló 
felhasználásának a NET SEND 
parancs, amelynek ha tarto- 
mánynevet adunk meg, akkor 
a tartomány összes bejelentke- 
zett felhasználójához eljut az 
üzenetünk, de úgy ám, hogy 
a NET SEND szépen egyesé- 
vel, Unicast címzéssel kiérte- 
síteni mind a 3634 bejelent- 
kezett felhasználót. 

A Unicast címzés használata sokszor erőforráspazarlással jár, mert sok 
gép megcímzése nem lehetséges egyetlen csomaggal. 


Miután ilyen szépen leszidtuk mindkét címzésmódot, lássuk, mit 
nyújt a Multicast! 


Csoportos címzés - a Multicast 

A Multicast létjogosultságát a fenti egy-két példa is ékesen bizo- 
nyította. Nem vitás, hogy például több résztvevős videokonferen- 
ciázás esetén Unicast címzéssel pillanatok alatt eldugulna a há- 
lózat, hisz minden beszélő fél videó és audióadatát egyenkén el 
kellene küldeni a hálózaton, ha hat résztvevő van, hát hatszor- 
hatszor (-36). A Broadcast is ugyanilyen rossz lenne, mert bár le- 
hetővé válna, hogy a konferenciaanyagot egy példányban küldjük 


2eNHeé. HY. 





A Broadcast címzés 
használata sokszor 
erőforráspazarlással jár, 
mert válogatás nélkül 
minden gép megkapja 
a csomagot. 
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A el, de bizony ilyenkor a videokonferencia becsorogna 

4 A a hűtőszekrény Ethernet kártyáján is, ahol természe- 

tesen némi feldolgozás után a szemétre kerülne. Az 

alábbi ábra az ideális megoldást mutatja, ahol egy 

feladó (a bal alsó sarokban) egyszerre nulla, vagy több fel- 
használónak küld adatot, egyetlen példányban! 
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5 A csoportos címzés elvi felépítése. De mi lesz a gyakorlattal? 









































A gyakorlati megvalósításnál azonban számtalan elvi problé- 

ma vetődik fel: 

1. Mi legyen a protokollszintű, végponttól-végpontig kísérő 
címzéssel, az IP-vel? 

2. Hogy lehetne megmagyarázni hálózati kártyák egy csoport- 
jának, hogy ők innentől egy brancsba tartoznak? 


IP címzés Multicast adatforgalomnál 
Kézenfekvő elgondolásnak tűnik a csoport tagjainak felruházása 
egy közös IP címmel, ám ez több kérdést is felvet. 
"0 Ha több gépnek egyszerre azonos IP címet adunk, azt nem 
IP cím ütközésnek hívják? Mit szól ehhez az oprendszer? 
"0 Ha egy csomó gépnek azonos az IP címe, de külön alhálóza- 
ton vannak, akkor vajon hogyan kommunikálnak egymással? 
Az útválasztón keresztül? Miért? Hogyan? 
0 Ki fogja beállítani a közös IP címet? A júzer? 
Gordiuszi csomó, de ha odasuhintunk a kardunkkal, tüstént ki- 
bomlik. A csoport minden gépére beállítandó IP cím az IANA ál- 
tal lefoglalt Multicast IP tartományból származik (D osztályú, 
224.0.0.0-239.255.255.255), s mint ilyen, az operációs rendsze- 
rek részéről különleges bánásmódban részesítendő, IP cím ütkö- 
zést sikítani illetlenség. A címtartományból látszik, hogy valószí- 
nűleg nem lesz elegendő Multicast címünk az Internet összes, 
kamerával felszerelt gépének ellátásához, mely csoportot akar al- 
kotni társaival. Ez igaz. Azonban egyelőre nincs olyan nagy tü- 
lekedés, hogy fogyóban lenne e címtartomány. S hogy ki fog- 
ja beállítani az adó IP címét? Vagy kézzel a rendszergazda (ha 
egy odabetonozott, központi médiakiszolgálóról van szó), 
vagy dinamikusan (ha egy ad hoc konferencia van kibontako- 
zóban). Ez volt a könnyebbik eset, a közös címre küldött cso- 
magot majd szépen az IP leszállítja a megfelelő gépekre. De 
mit szól ehhez az Ethernet? 


Ethernet címzés Multicast adatforgalomnál 

Az a bökkenő, hogy a hálózati kártyák alapesetben összesen két 
MAC Addressre ,harapnak", a sajátjukra, és a Broadcastra (em- 
lékeztetőül: FF-FF-FF-FF-FF-FF) . Csoportos, vagyis több gépen kö- 
zös MAC Addressről ki hallott? Olyan nincs! Vagy mégis? A 1112- 
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es RFC elolvasása után (Host Extensions for IP Multicasting) ki- 

derül, hogy ilyen állat márpedig van! Mégpedig az Ethernet kár- 

tyák azon tulajdonságának kihasználásával, hogy legtöbbjükön 

a gyári eredeti MAC Addressen kívül további MAC Addressek 

állíthatók be, melyekre szintén , harap". Már csak azt kell bizto- 

sítani, hogy az azonos csoportba tartozó gépek azonos dinami- 
kus MAC Addresst vegyenek fel. De mi legyen az? 

Kézenfekvő megoldásnak tűnik a dinamikus MAC Address képzé- 

sénél felhasználni a csoport tagjain amúgy is közös IP címet. 

Ám az IP cím négy, míg a MAC Address 6 bájtos. Sebaj! Kiált fel 

a szabvány, és a következőket mondja: 

1. A hat bájtos MAC Address első három bájtja legyen 
01-00-5E. Ez a lefoglalt Ethernet címtartomány Multicast 
címzésre van fenntartva. 

2. A hátsó három bájton még 24 bitnyi infó férne el az IP cím- 
ből - de az sajnos 32 bites! 

3. AD osztályú IP címekben a hasznos bitek száma amúgy is 
csak 28, mivel az első bájt első négy bitje mindig 1110 (deci- 
málisan 224-239). Ha még ,lemondunk" néhány bitről, és 
megelégszünk az utolsó 3 bájt felhasználásával, akkor már meg 
is kapjuk a csoport tagjain közösen használandó MAC Addresst. 
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MAC address 01 00 5E OD 2D 01 


5 Bepillantás a Multicast MAC Address kotyvasztás rejtelmeibe 


Ezzel a módszerrel jól láthatóan sajnos olyan MAC Addresseket ka- 
punk, ami több IP címből is előállhat, de hát ilyen az élet, a kom- 
patibilitás, meg a későn ébredés. Tetszettek volna már 1969-ben 
előállni a nyavalyás videokonferencia ötletével! Ez biza így le van 
írva a szabványban, még ha kissé szabadosan fordítottam is: 


Because there are 28 significant bits in an IP host group 
address, more than one host group address may map to the 
same Ethernet multicast address." 


Ez van. Ezt a kis konfúziót majd az oprendszer lesz szíves leke- 
zelni-lenyelni. 


Címek 

Eddig még nem ejtettem szót a Multicast csoporthoz történő 

csatlakozás mibenlétéről, s arról, vajon hogyan jövünk rá, hogy 

egy olyan csoport alakult, aminek hej de jó lenne tagjává válni. 

"7 Előszöris vannak olyan előre megadott csoportok, melyek- 
nek számítógépünk by default része. Ilyen például a 224.0.0.1 
cím (All Systems on this Subnet, RFC1112) és a 224.0.0.2 (All 
Routers on this Subnet). Csak érdekességképpen említem (az 
1700-as RFC böngészése közben akadtam rá) , hogy vannak egé- 
szen speciális lefoglalt Multicast címek is, például a 
224.0.1.24, mely microsoft-ds szerepre van lefoglalva, s a cím 
felelőse arnoldmomicrosoft.com. Ez a válaszom a NetAcade- 
mia listán feltett kérdésre, hogy vajon mi ez a cím. 

"? Másodszor, szert lehet tenni a kívánatos Multicast címre 
például a vállalati Intranetről, MADCAP kiszolgálótól (egy- 
fajta DHCP Server, de multicast címeket oszt). A belső, dina- 
mikus Multicast címeket a szabvány szerint a 239.192.0.0 
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tartományból kell osztani (hasonlóan a belső Unicast IP cí- 
mek fenttartott tartományaihoz: a 172.16.0.0-ról mindenki 
tudja, hogy belső IP cím) 

"b Harmadszor, internetszolgáltatótól leosztott Multicast címünk 
is lehet, amely megtalálhatóvá teszi publikus Multicast ki- 
szolgálónkat (ugyanolyan egyedi forráscím, mint webserve- 
rünk fix IP címe). A publikus Multicast címek 233-mal kez- 
dődnek, utána két bájton a szolgáltató Autonomous System 
száma szerepel, majd az utolsó bájtról ad a szolgáltató ne- 
künk egyedi Multicast címet. (Magyarországon persze ez az 
egész nem működik, mert a szolgáltatók útválasztói nem en- 
gedik át a Multicastot...) 

A megfelelő IP címek birtokában már mehet is a Multicast. A 

Windows 2000 Resource Kit tartalmaz egy mini-Multicast ügyfél- 

kiszolgáló párost, hogy két végpont között PING szerű kapcso- 

lattesztet végezhessünk: ez a MCAST.EXE. 

Multicast PING elindítása: 


mcast /send /grps:224.2.2.2 /srcs:172.1b.0.3 
Multicast PING fogadása: 
mcast /recv /grps:224.2.2.2 


Ideális esetben a válasz: 


Started.... Waiting to receive packets... 

Received [2]: ([GO00D] SRC- 272.1b.0.3 GRP- 
d04.2.2.e TTL- 5 Len- 85b 

Alkalmazások 


Végül tekintsük át, mi mindenre használja a Multicastot már ma 

is operációs rendszerünk: 

0 A Windows 2000 Serverben található Media Services segít- 
ségével központi adásban lehet , sugározni" a főnök beszé- 
dét, PowerPoint bemutatókat, tanfolyamokat. 

0 Az összes Windows (98-tól felfelé) képes megtalálni a háló- 
zatán a Default Gatewayt az All IP Routers címre küldött 
Router Solicitation üzenettel 

0 Az Exchange 2000 Conferencing Server a MADCAP (Multicast 
DHCP) felhasználásával sokszereplős Multicast konferenciá- 
zást tesz lehetővé. Kipróbálva! 

0 Az NLBS (Network Load Balancing System) fürtök Multicast 
címzéssel oldják meg, hogy a munkaállomások egyetlen IP 
címet használhassanak a fürt szolgáltatásainak kihasználá- 
sára. Erről bővebben a tech.net magazin tavaly júniusi szá- 
mában értekeztem, Network Monitor trace fájlokkal súlyos- 
bítva a mondanivalómat. 
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Más gyártók is ráharaptak az egyszeres adatátvitel A 
miatt a Multicastra, például a klónozószoftverek (pl. 4 A 


GHOST) már elég régóta lehetővé teszik, hogy ha egy- 
szerre másolok X darab gépre valamit, akkor az csak egy 
példányban menjen át a hálózaton. 


Multicast buktatók 

Minden előnye és fantasztikussága dacára a Multicast nem univer- 
zális eszköz. Nem lehet vele valódi TCP csatornát létrehozni, mivel 
a TCP csatornának sajnos minimum és maximum két vége van. Kor- 
látot szabhat bevezetésében az a szomorú tény is, hogy egyes ré- 
gebbi hálókártyák nem képesek dinamikusan új MAC Addresst fel- 
venni, enélkül pedig a Multicast nem működik. Útválasztós kör- 
nyezetben sajnos mindegyik érintett routernek ismernie kell a 
Multicastot, s ez az olcsóbb eszközök esetén nem teljesül. Ilyen- 
kor dobjuk ki az olcsó eszközt, és routoljunk Routing and RAS-sal! 
Igaz, a Multicastalapú alkalmazások száma egyelőre nem végtelen, 
de egyre szaporodnak, így nagy routercsereberék előtt állunk! 


Mire nem tértem ki? 

Terjedelmi korlátok, valamint az elbonyolódó lehetőségek miatt 
nem emlékeztem meg többek között az IGMP protokollról, mely 
a csoportba be- és kilépés vezérprotokollja, nem néztük meg a 
Multicast és az útválasztók harcát, valamint a multicast feletti 
MTP , csatorna" protokollt sem, de az erősebb idegzetűek ked- 
véért, íme a forrásmunkák, ahol tovább lehet olvasni: 


RFC1112: — Host Extensions for IP Multicasting 

RFC 1301: Multicast Transport Protocol 

RFC 2588: IP Multicast and Firewalls 

RFC 2730: . MADCAP 

RFC 2908: The Internet Multicast Address Allocation 


Architecture 
RFC 2236: — IGMP 


Fóti Marcell 
marcellfonetacademia.net 
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Delegate-ek és események (IV. rész) 


Az előző számban megismerkedtünk a delegate-ekkel, és láttunk egy egyszerű 
példát a használatukra. Valójában sokkal többet tudnak, mint amit akkor felvá- 
zoltunk, képesek sok metódusreferencia meghívására is. Miután kiteljesítjük a ko- 
rábban megkezdett atomreaktoros példánkat, rájövünk, hogy az ott végzett mun- 

kánk jelentős részét megspórolhatjuk multicast delegate-ek felhasználásával. 


Multicast delegate-ek 

Delegate-ek felhasználásával egyszerűen meg tudtuk oldani a megfi- 
gyelők (szivattyúk) értesítését, azonban nekünk kellett egy listában 
nyilvántartani a hívandó metódusokra hivatkozó delegate-eket. Pedig 
ezt is tudják, csak nem a közönségesek, hanem a multicast típusúak. 
A multicast delegate egy olyan konstrukció, amelynek több mint 
egy célpontja is lehet, azaz több mint egy metódust is képes 
meghívni. A metódushívások sorrendje nem determinisztikus, és 
nem garantált, hogy mindegyik meghívódik, ha valamelyik hí- 
vott ,felemel" egy kivételt (Exception) és nem kezeli le helyben, 
azaz a kivétel eléri a delegate-et. 

Ismétlésképpen az előző számban felvázolt példában a lényegi 
rész a következő volt: 


7//A szivattyúosztályokba hívó delegate 
public delegate void SzivattyuBekapcsolas( ) ; 
7/7/A szivattyúk hívandó metódusait tároló 
//delegate-ek listája 
private ArrayList szivattyuk - new ArrayList(); 
77A szivattyúk bekapcsoló metódusainak hívása a 
delegate-eken keresztül 
foreach(SzivattyuBekapcsolas szbekapcsolo 
in szivattyuk) ( 
szbekapcsolo( ) ; 


) 


Azaz egy ArrayList-ben (- nyújtható tömb) tároltuk a szivattyúk 
bekapcsolását végző metódusokra hivatkozó delegate-eket, és 
egy ciklusban egyenként végeztük el a metódushívásokat a del- 
egate-eken keresztül. 

Hasonlóan működik a multicast delegate is. Van egy belső listá- 
ja, aminek Invocation List (hívási lista) a neve. Ez valójában na- 
gyon egyszerűen van megvalósítva, minden multicast delegate- 
nek van egy belső (private)  prev nevű multicast delegate refe- 
renciája, ami a következő hívandó multicast delegate-re mutat. 
Amikor egy delegate-en keresztüli metódushívást hajtunk vég- 
re, akkor a delegate-híváslánc végigfut a prev-ek mentén, és 
minden delegate meghívja a Method és a Target jellemzői mö- 
gött tárolt osztály vagy objektumpéldány megfelelő metódusát. 
A Target egy referencia arra az osztálypéldányra, amiben a cél- 
metódust meg kell hívni. Nyilván ennek értéke null, ha statikus 
(osztályszintű) metódust hívunk meg. 

Hogyan kell definiálni egy multicast delegate-et? Igazából pont 
úgy, mint egy ,közönségeset", ahogy az előbb a SzivattyuBe- 
kapcsolas példában is láthattuk. Ez azt jelenti, hogy eddig is 
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multicast delegate-et hoztunk létre, csak nem használtuk ki a 
képességeit? Igen! A hivatalos leírás alapján akkor lesz egy de- 
legate deklarációból multicast delegate, ha a delegate által rep- 
rezentált metódusnak void a visszatérési értéke. Azért, mert egy 
multicast delegate hívásakor úgyis csak az utoljára meghívott 
metódus visszatérési értékét kaphatjuk vissza, a többi elveszik, 
nem tárolja a multicast delegate. 

Na, de mi van azokkal a metódusokkal, amelyeknek ugyan van 
visszatérési értéke, de nem mindig akarjuk felhasználni? Azaz 
mindenképpen multicast delegate-et akarunk használni az 
egyszerű csoportos hívás miatt, és nem érdekel minket, ha el- 
veszik a metódus visszatérési értéke. Ha a voidos szabály igaz 
lenne, akkor ilyet nem tehetnénk. De szerencsére tehetünk. A 
lefordult kódokat IL Disassemblerrel megtekintve az összes de- 
legate-ből multicast delegate lesz (legalábbis Windows platfor- 
mon és C4t fordítóval) . Miért? 

Amikor a Microsoftnál a delegate-eket tervezték, különválasz- 
tották a két típust, és az egyiket a System.Delegate, a másikat 
a leszármazott System.MulticastDelegate osztályban valósítot- 
ták meg. A megkülönböztetés zavarta a fejlesztőket, a fordító 
(compiler) írókat, a CLR csapatot és még sokan másokat, ezért 
össze akarták őket vonni egy osztályba, amely tulajdonképpen 
multicast delegate, csak bizonyos esetekben 1 hosszúságú a hí- 
vási listája. Azonban ez az ötlet túl későn jött, és túl sok kiha- 
tása lett volna ez egész .NET framework-re, ezért már nem mer- 
ték meglépni a változtatást. Majd a jövőben... 

Azaz most már tudjuk, hogy a SzivattyuBekapcsolas valójában 
egy multicast delegate. Hogyan kell hozzáadni a hívandó a me- 
tódusokat? A Delegate osztály Combine statikus metódusát erre 
találták ki. Ő vagy két delegate-et vár paraméterül, vagy dele- 
gate-ek tömbjét. Az előbbit használjuk leggyakrabban, amikor 
egy multicast delegate-hez hozzá kell adni egy újabb hívandó 
metódust. Eddig így nézett ki a hívandó metódusokat (bekap- 
csolandó szivattyúkat) regisztráló metódusunk: 


public void SzivattyuHozzaad(object szivattyu) ( 
szivattyuk.Add(szivattyu); 
) 


Mivel egyszerűen definiálhatunk egy multicast delegate-et, már 
nem is kell a delegate-eket tároló ArrayList: 
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77/ Ssummary2 

/// Ebben a multicast delegate-ben tároljuk 

/// a szivattyúk listáját 

777/ £/summary? 

private SzivattyuBekapcsolas szbekapcs - null; 

public void SzivattyuHozzaad( 
SzivattyuBekapcsolas szivattyu) 


szbekapcs - (SzivattyuBekapcsolas) 
Delegate.Combine( 
szbekapcs, 
szivattyu); 
) 


A Combine statikus metódusként van megvalósítva, így nem kell 
foglalkozunk azzal, hogy az szbekapcs delegate-ünk már tényle- 
gesen hivatkozik egy delegate-re, vagy még nem, így null az ér- 
téke. Az első híváskor az szbekapcs-ban levő null és a szivattyú- 
ban kapott delegate kombinációjaként az szbekapcs multicast 
delegate-ünk egy metódushivatkozást fog tartalmazni. 

A SzivattyuHozzaad második hívásakor az előbbi delegate-ünk 
meghízik, hozzáláncolódik az újabb hívandó metódusra hivat- 
kozó delegate. 

A metódusok meghívása éppoly egyszerű, mint a sima delegate- 
eknél, csak le kell ellenőriznünk, hogy egyáltalán inicializálva 
van-e a delegate referenciánk, vagy null az értéke, mert esetleg 
még nem is adtunk hozzá hívandó metódusokat: 


//Szivattyúkat elindítani 
if (szbekapcs !5 null) ( 

szbekapcs();  //delegate-en keresztüli hívás 
) 


Ez az ellenőrzés fontos a nem multicast delegate-eknél is. 

Ha hozzá lehet adni egy delegate-et a hívási listához, akkor va- 
lószínűleg ki is lehet venni onnan. A Delegate.Remove-ot erre 
találták ki. Első paramétere a hívási lista feje (a multicast dele- 
gate-ünk) a második az eltávolítandó delegate: 


szbekapcs - (SzivattyuBekapcsolas) 
Delegate.Remove( 
szbekapcs, 
szivattyu); 


Teszteljük az új, multicast delegate-ekre épülő osztályunkat (a kód 
teljes környezetében a [1] címről letölthető példában tekinthető meg): 


SzivattyuBosch b - new SzivattyuBosch( ); 
SzivattyuAKG a - new SzivattyuAkG-( ); 
HoerzekelollulticastbDelegatte hm - new 
HoerzekelolőulticastDelegatte( ) ; 
SzivattyuBekapcsolas szi - new 
SzivattyuBekapcsolas(a.Indit); 


hm.SzivattyuHozzaad(szl); 
hm.SzivattyuHozzaad( 
new SzivattyuBekapcsolas(b.Bekapcs) ) ; 
hm.Meres( ) ; 
Console.WriteLine("Most pedig kivonjuk az egyik 
Sszivattyút."); 
hm.SzivattyuEltavolit(szl); 
hm.Meres( ) ; 
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Ha jobban megnézzük a kódot, akkor látható, hogy 
trükköztem, mert megjegyeztem az a.Indit-ra hivat- 

kozó delegate-et, mert tudtam, hogy később el aka- 

rom távolítani a listából. 

Azonban a gyakorlatban általában ez nem így történik 
meg, így kérdés, hogy miután többször létrehozunk delegate re- 
ferenciákat ugyanarra a metódusra, a Delegate.Remove észreve- 
szi-e, hogy tulajdonképpen ugyanarról a delegate-ről van szó? 


SzivattyuBekapcsolas szl - 
new SzivattyuBekapcsolas(a.Indit); 
SzivattyuBekapcsolas szli - 
new SzivattyuBekapcsolas(a.Indit); 


Sz1 ugyanaz mint sz11? Nos, referenciájukat tekintve nem: 


Console.WriteLine( 
object.ReferenceEguals(szl, szl1)); 
false 


Azaz van két System.Delegate (leszármazott) objektumunk, 
amelyek a saját értelmezésünk szerint ugyanarra a hívandó me- 
tódusra mutatnak, azaz számunkra egyformák. És valóban, az — 
operátor már ennek megfelelően működik: 


Console.WriteLine(szl 5-5 szll); 
true 


Ez egy jó példa arra, hogy érdemes felüldefiniálni egy operátor je- 
lentését, ha az intuitív működése nem ugyanaz, mint az alap- 
értelmezett működés. Hasonló a helyzett a string típusnál is, ahol 
az s nem referencia, hanem érték szerinti összehasonlítást jelent. 
Az eddigiek miatt az alábbi kódrészlet éppúgy (jól) működik, 
mint a hárommal ezelőtti blokkban látható: 


hm.SzivattyuHozzaad( 

new SzivattyuBekapcsolas(a.Indit)); 
hm.SzivattyuEltavolit( 

new SzivattyuBekapcsolas(a.Indit)); 


És még nincs vége az operátor felüldefiniálásoknak! Az előbbi 
Combine és Remove metódushívásokat végrehajthatjuk a -- és a 
- operátorok segítségével is: 


szbekapcs - szbekapcs t szivattyu; 
szbekapcs - szbekapcs - szivattyu; 


A 34. hozzáad egy delegate-et a listához, a - pedig kiveszi. Leg- 
gyakrabban az -4- és a -- formában, az értékadás operátorral 
együtt szoktuk használni: 


szbekapcs t-z szivattyu; 
szbekapcs -- szivattyu; 
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Ennél tömörebben nem lehet megfogalmazni a kíván- 

ságunkat. Valójában a két operátor Delegate.Combi- 

ne és Delegate.Remove-re fordul le, amint az alábbi 
disassemblált IL részletből is látszik: 


TTTEEETEYTEKTE OTT ETETETT] 





-nethod public hidet 
k 





44 Code size 
-maxstack 2 
(1anguage "(3FS162F8-07C6-1103-9059- 00COAFAJOZAT)" , "(9ABASCA-EGEV-1102-903F-BOCONFAIOZAT I" , 


21 (x18) 


szbekapcs 





z szívattyu; 
IL. 0090: 1garg.0 


" class Szívattyuflekapcsolas Hoerzekeloltulticastbelegattel: :szbekapcs 
M0007:  1darg.4 
MZO008£ call 


IL 0004: castclass Szívattyubekapcsolas 
M70912: stFld €lass Szívattyubekapcsolas Hoerzekelottultícastbelegattel::szbekapcs 
[/docAuhr] , 
IL 0917: ret 
al 





g instance void  Szivattyulozzaadt(ciass Szívattyulekapcsolas szívattyu) cil nanaged 


"(SAB69008-6611-1103-BD2A- ot 
File rertdocunents and settingstsoci.dotnetző09iny docunentstarticiesinetimetsidelegatesandeventsíszívattyuzas es 


€lass [nscorlibjsysten.Delegate (nscorlibjsysten.Delegate::Conbínetclass [nscorlíbjsysten.Delegate, 
€lass [nscorlib]systen.Delegatej 


Egy atomreaktor esetén ez nem túl szerencsés, habár estek már 
le műholdakat földkörüli pályára állító rakéták hasonló okokból. 
(Mielőtt valaki félreértené a C$ és a .NET nem műhold vagy atom- 
reaktor vezérlésre van kitalálva. ) 

ia — Kapjuk el a kivételeket a hívó oldalon: 






try ( 
szbekapcs( ) ; 

) 

catch(Exception e) ( 
Console.WriteLine(e.ToString( ) ) ; 





Megfigyelhető, hogy a Combine kimenetét a visszakonvertáló 
utasítást (castclass) automatikusan megírja helyettünk a fordító. 


Vegyük kézbe a vezérlést! 

A multicast delegate könnyedén végighívja a listában található 

összes metódust. Azonban, mi van, ha valamelyik hívott metódus: 

"8 ,felemel" egy kivételt (raise an exception) 

"$ nagyon sokáig elmolyol magában, vagy egyáltalán vissza 
sem tér a hívásból 

Az első esetben vagy elszáll a teljes program, vagy ha lekezeljük 

a kivételt a delegate hívásakor, akkor megáll a hívási láncolat. A 

második esetben a többi metódust csak későn vagy soha nem fog- 

ja meghívni a delegate. Lássunk az elsőre egy példát: 


public class RendetlenSzivattyu ( 
public void Puff() ( 
Console.WriteLine("Most dobok egy kivételt."); 
throw new 
Exception("Én vagyok a rendetlen szivattyú!"); 


Rakjuk be a renitens szivattyút a listába, majd hívjuk meg a mé- 
rést, amely elindítja a multicast delegate automatikus hívási 
láncát: 


RendetlenSzivattyu rsz - new RendetlenSzivattyu( ); 
hm.SzivattyuHozzaadk( 
new SzivattyuBekapcsolasírsz.Puff)); 
hm.Meres( ) ; 
A hívás kódja a Meres() mögött: 


szbekapcs( ) ; 


Az eredmény, hogy elhasal a programunk: 


h elindult. 
- operátorok 


elindult 
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Most már nem repül el az egész program, de a kivétel után nem 
folytatódik a maradék delegate meghívása. Ez baj, nagy baj. 
Mit lehet tenni? 

A kezünkbe kell venni a vezérlést. A multicast delegate van 
olyan kedves, és a kezünkbe adja az általa összeláncolt összes 
delegate-et egy tömbben. Ezek után már csak végig kell men- 
nünk a tömbön, és egymás után meghívni a delegate-eket. Mi- 
vel hívásonként le tudjuk kezelni a hibákat, garantáltan végig 
tudjuk hívni az összes résztvevőt. A bűvös metódus a GetInvo- 
cationList(), és az alábbi módon használható: 


Delegate[] d 5 szbekapcs.GetlnvocationList(); 
foreach(SzivattyuBekapcsolas sz in d) ( 

try ( 

sz(); 

) 

catch(Exception e) ( 

Console.WriteLine(e.ToString( ) ) ; 

) 


Valójában még azt is tudjuk melyik szivattyú hibázott, mert a 
delegate Target jellemzőjéből kiolvasható a hivatkozott objek- 
tum, így annak minden nyilvános jellemzőjét kiolvashatjuk. 
Most ilyenünk nincs, de a hibázó osztály nevét könnyedén ki- 


nyerhetjük: 


Console.WriteLine("A hibás osztály: (0) ", 
sz.Target.GetType( ) . ToString( ) ) ; ú 


Ezek után melyik módszerrel éljünk? Az automatikus hívást, vagy 
a kézi végiggyalogolós módszert? Nos, ha nem bízunk meg a hí- 
vottakban, akkor marad a kézi módszer. Ha tudhatjuk, hogy azok 
nem ,emelnek" kivételeket, és nem kell minden egyes hívás 
visszatérési értéke (amit csak az egyenkénti hívással nyerhetünk 
ki) , akkor kényelmesebb az automatikus módszer. 


Események 

Láthattuk, hogy a delegate-ek segítségével könnyedén ki lehet 
építeni olyan futásidőben felépíthető objektumok közötti kommu- 
nikációt, amelyben egy objektum értesíthet bármely más objektu- 
mot belső állapotváltozásáról. Általában ezt nevezzük klasszikus 
értelemben vett eseménykezelésnek. Az eseményforrás (publisher) 
értesíti a feliratkozókat (subscriber) valamely számukra érdekes 
belső állapotváltozásáról. Mivel mindezt könnyedén meg lehet ol- 
dani delegate-ekkel, akkor minek az események (events)? 
Valójában munkát spórolnak meg nekünk, és lehetetlenné teszik 
azt, hogy egy óvatlan feliratkozó leiratkoztasson valaki mást 
egy eseményforrásról. 


zÜG8E. D4; 


Nézzük az előbbi példánkat. Az eseményforrásként tetszelgő Hoer- 
zekelo osztályunkban volt egy private, a külvilág számára elérhe- 
tetlen multicast delegate (szbekapcs), és ehhez lehetett hozzáad- 
ni, illetve elvenni feliratkozókat. Ehhez írnunk kellett két nyilvá- 
nos elérőmetódust, a SzivattyuHozzaad és a SzivattyuEltavolit-ot. 
Mi van, ha százféle eseményről akar értesítést küldeni egy osz- 
tály? Akkor bizony száz delegate-et és kétszáz elérő metódust 
kell írnunk. Ez nem túl ambiciózus feladat. Ezért a tizedik táján 
(lustaságból) úgy döntünk, hogy elfelejtjük az 0OP-s egységbe- 
zárás és absztrakció elvét, és nyilvánossá tesszük a további del- 
egate-eket. Valahogy így: 


public class HoerzekeloEventRavezetes ( 
public SzivattyuBekapcsolas szbekapcs; 


Ezek után a feliratkozók nagyon egyszerűen rácsatlakozhatnak a 
delegate által szolgáltatott értesítési láncra, a már megismert 
4z operátorral: 


HoerzekeloEventRavezetes he - 
new HoerzekeloEventRavezetes( ) ; 
he.szbekapcs tz new SzivattyuBekapcsolas(a.Indit); 


Ugye milyen egyszerű? Semmi cicó, használjuk a nyilvános de- 
legate tagot. Ám ekkor csap be a ménkő! A következő szivattyú 
elfeledkezik róla, hogy már valaki várja az értesítéseket, és ar- 
cátlanul berakja magát a másik (előzőek) helyére: 


he.szbekapcs - 
new SzivattyuBekapcsolas(b.Bekapcs); 


Figyelem, nem 4--t, hanem --t használt! Megteheti? Meg! Tudunk 
ellene védekezni? Nyilvános delegate-tel nem, csak a korábban lá- 
tott elérő metódusokkal. Ott tartunk, ahonnan elindultunk. Ki 
akartuk kerülni az elérő metódusok megírását, s most tessék, nél- 
külük nem lehet biztonságos eseménykezelést megvalósítani. El- 
jött az ideje, hogy belépjen a felmentő sereg, az esemény (event)! 
Az esemény nem más, mint egy delegate-re épülő réteg, amellyel 
pont az előbb vázolt problémát oldhatjuk meg anélkül, hogy elérő 
metódusokat kellene írnunk. Írja meg azt a fordító, nem? 

Egy event-höz mindig definiálnunk kell egy delegate-et, ez írja le 
az esemény által értesíteni kívánt metódusok formátumát. Tulaj- 
donképpen a metódushívásokat teljes egészében a delegate való- 
sítja meg. Az előbbi példánk így néz ki event-öt felhasználva: 


public event SzivattyuBekapcsolas szbekapcs; 


Azaz csak annyi a változás, hogy az osztálybeli delegate referen- 
cia létrehozásakor az event kulcsszót írjuk a deklaráció elé (vö. 
hárommal korábbi kódrészlet). 

Kívülről, a feliratkozók oldaláról semmi különbséget nem veszünk 
észre, egy eseményre ugyanolyan módon lehet feliratkozni, mint 
ahogyan a multicast delegate-nél láttuk, a --— operátorral: 


HoerzekeloEventtel hev - new HoerzekeloEventtel( ); 
hev.szbekapcs t- new 
SzivattyuBekapcsolas(a.Indit); 
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Azonban az ármánykodókra rossz világ vár: 


hev.szbekapcs - 
new SzivattyuBekapcsolas(b.Bekapcs); 
Hiba: 
The event "HoerzekeloEventtel.szbekapcs" can only 
appear on the left hand side of $z or --. 


Hát nem ezt akartuk? Az eseményre bárki rácsatlakozhat (és le- 
csatlakozhat róla, --), de nem üthet ki másokat a hívási listából. 
Igazából ezért hozták létre az eseményeket. 

Mit csinál a fordító a háttérben? Valójában a publisher osztályban 
létrehoz egy private delegate-et az event-ben megjelölt típussal 
(private SzivattyuBekapcsolas szbekapcs). Ezen felül ír két elérő 
metódust, az egyik neve add eseménynév, a másiké remove ese- 
ménynév. Esetünkben add szbekapcs és remove szbekapcs. Ezek 
a nyilvános elérőmetódusok, és a 4-—, -— eseménykezelő hoz- 
záadások esetén ezeket hívja meg a fordító által generált kód. Mi- 
vel valódi hívásokat végző delegate nem érhető el nyilvánosan, 
érhető miért nem megy az - operátoros értékadás. 

Emellett még egy szbekapcs nevű nyilvános esemény is bekerül 
a lefordított kódba, ezen keresztül találják meg a valódi add és 
remove metódusokat a nyelvi fordítók. 

A delegate-eket olyan formátumúra írjuk, ahogyan nekünk tet- 
szik. Ez igaz az eseményekre is, azonban a framework dokumen- 
táció számos útmutatást ad arra nézve, hogyan írjuk meg az ese- 
ménykezelésünket. Ha alkalmazkodunk ehhez, akkor a feliratko- 
zók egységes módon tudják lekezelni az eseményeket. 

Az események nevét lehetőleg igékből képezzük, mindenféle elő- 
tag nélkül: Closed, Closing. Általában az ige folyamatos alakja 
(Closing) azt jelezi, hogy még beleavatkozhatunk az eseménybe, 
a múlt idejű (Closed) azt, hogy már csak értesítést kaptunk egy 
olyan eseményről, amibe már nincs beleszólásunk. 

Az események mögötti delegate neve legyen az esemény neve 
plusz az EventHandler (eseménykezelő) szócska: ClosingEvent- 
Handler, ClosedEventHandler. Mivel az események forrása érde- 
kes lehet a hívottaknak, ezért az esemény első paramétere min- 
dig legyen sender nevű és a típusa legyen object. A publisher ezt 
töltse fel saját magára mutató referenciával (this). Ezen felül az 
eseményre vonatkozó további paraméterek szállítására használ- 
junk egy második paramétert is, amely az EventArgs osztály egy 
leszármazottja legyen, és a neve legyen XxxEventArgs. 

Ezek a legfontosabb iránymutatók, azonban a framework doku- 
mentáció még további javaslatokat is tartalmaz az Event Naming 
Guidelines részben. Érdemes egyszer átolvasni. 


Soczó Zsolt 
MCSE, MCSD, MCDBA 
Zsolt.Soczo(onetacademia.NET 
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XMLgessünk 


Az XML Schema (I. rész) 


Számtalanszor hivatkoztunk már XML sorozatunkban az XML sémára, így hát itt 
az ideje, hogy közelebbről megismerjük. Ebben a részben áttekintjük az alap- 
ismereteket, és megnézzük az egyszerű típusok képzésének fortélyait. 

A következő részben áttekintjük az összetett típusok kialakításának részleteit, 
a harmadik, záró részben pedig tervezési mintákat nézünk át újrafelhasznál- 
ható és jól olvasható sémák írásához, valamint megnézzük milyen eszközökkel 
lehet ténylegesen kihasználni a sémák adta előnyöket. 


Kezdjük az alapokkal. Mi az a séma? 

Az xml sémaleíró nyelvek célja, hogy formális leírást adjanak 
xml dokumentumosztályok definiálására. Másképpen megfogal- 
mazva nyelvtani leírások, amelyek segítségével xml struktúrák 
által ábrázolni kívánt üzleti szabályokat definiálhatunk. 
Egy-egy xml dokumentumminta nem elég az egyértelmű leírás- 
hoz. Nézzük például az alábbi xml töredéket: 


Khelyzet2 
Kszelesseg247.7742b2C/szelesseg2 
XKhosszusag224 . 230234£/hosszusag? 
Cbizonytalansag mertekegyseg-"meter"210 
€K/bizonytalansag? 

cx/helyzet?2 


Ránézésre sejthetjük, hogy egy hely földrajzi koordinátáit írja le 
ez a töredék. De milyen pontosságú a két koordinátát ábrázoló 
szám? Milyen határok között mozoghatnak az értékek? Kötelező-e 
megadni a bizonytalanság értékét? Milyen mértékegységeket hasz- 
nálhatunk? Ezek mind nagyon fontosak az adatok értelmezéséhez, 
és ezeket kellene valahogyan formálisan leírni. Erre való a séma. 


Mit ír le egy séma? 

2 Definiálja, milyen elemek és attribútumok lehetnek egy do- 
kumentumban. 

Definiálja az elemek egymásba ágyazását. 

Definiálja a gyermekelemek sorrendjét. 

Definiálja a gyermekelemek számát. 

Definiálja, hogy egy elem üres, szöveget, vagy további gyer- 
mekelemeket tartalmaz. 

"8 Definiálja az elemek és attribútumok adattípusát. 

"0 Alapértelmezett értéket definiál elemekhez és attribútumokhoz 
Egyszerűbben megfogalmazva a dokumentum struktúráját, vala- 
mint a benne található adatok típusát és értelmezési tartomá- 
nyait adja meg. 


PÁddd 


Mit jelent az a szó, hogy validálás? 

A sémák egyik fő célja, hogy miután formális leírást adtak egy 
dokumentumosztályról, programozottan meg lehessen mondani, 
hogy egy konkrét xml dokumentumpéldány megfelel-e a sémá- 
nak? Ezt a folyamatot nevezzük validálásnak, és az olyan xml 
doksit, ami egy sémának megfelelő, validnak. 
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Mire jó a séma? 

Számos helyen használjuk a sémákat, Don Box szerint ,a séma 
a villanyáram és a melegvíz az xml technológiákban", azaz e 
nélkül nem lehet kulturáltan, komolyan xml-ben fejleszteni. 

Az első felhasználás a struktúradefiniálás. Hogyan magyarázom 
el az üzleti partnereimnek, hogy milyen formátumú xml doku- 
mentumokat várok például a megrendelések leírására? Ahelyett, 
hogy körbemagyaráznám a formátumot, egyszerűen adok neki 
egy sémát, és azt mondom, hogy így néz ki a megrendelőlap. 
Ebből a precíz leírásból ő már képes a sémának megfelelő xml do- 
kumentumokat generálni. Egyes eszközök (pl. SOL Server 2000) a 
séma minimális kiegészítésével azonnal képesek xml kimenetet 
generálni a táblák adataiból. 

Miután bejött hozzám egy megrendeléstétel, le kell ellenőriz- 
nem, hogy az tényleg a sémának megfelelő formátumú, azaz va- 
lidálásra használom a sémát. Validálás nélkül letárolni a kapott 
információkat (minimum erkölcsi) öngyilkosság. 

A SOAP által javasolt kommunikációs modellben a kommunikáló 
programok között xml formátumban utaznak az információk, pél- 
dául a távoli eljáráshívások paraméterei. Mivel mindkét oldal ob- 
jektumokban gondolkodik, szükség van egy olyan formális leírás- 
ra, amelynek segítségével a programozott típusokat (osztályok, 
interfészek, primitív típusok) automatikusan át tudjuk fordítani 
xml struktúrákká, és vica versa. A programozók objektumokban és 
tagváltozókban gondolkodnak, az xml pedig elemekben és attri- 
bútumokban. A két világ áthidalására a SOAP szabvány is az XML 
sémára bízza az összes olyan típus leírását, amelyet eleve ismer a 
séma (amit nem, azt kiegészítették a SOAP specifikációban). 


Milyen sémákat ismerünk? 

A legrégebbi sémaleíró nyelv a Document Type Definition, a DTD. 
Ő az SGML világból jött át, ám az XML világban nem igazán ha- 
tékony. A fő problémák vele: 

Nem xml formátumú 

Nem ismeri a névtereket 

Nem bővíthető 

Csak egy teljes dokumentumra alkalmazható 

Fő probléma: nem ismeri a programozott világban megszo- 
kott adattípusokat 

Világos volt, hogy le kell cserélni egy jobban ,xmlesített" séma- 
leírásra. Ez azonban nem volt egyszerű meccs. Többféle javaslat 
is napvilágot látott, név szerint a legfontosabbak: RELAX, TREX, 
Schematron, SOX, DSD, XDR és XML Schema. 
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A sémák egy része szabályalapú, más részük nyelvtani elemekből 
építkezik. A szabályalapúak általában fejlettebbek az xml doku- 
mentumpéldányok szabályellenőrzésében (validálás) , a nyelvtanala- 
púak pedig jobbak struktúra definiálásra. Az előbbire az egyik 
legfejlettebb nyelv a Schematron, az utóbbira az XML Schema. A 
szabályalapúakkal le lehet írni olyan környezetfüggő kötöttsége- 
ket is, amelyeket nem lehet nyelvtannal megfogalmazni. Például 
ha egy elemnek van x nevű attribútuma, akkor kell lenni y-nak is. 
Vagy ha egy elem szülője z, akkor kell legyen j nevű attribútuma. 
Ezzel szemben a nyelvtanalapú sémákból remek programozott ob- 
jektumokat lehet generálni: osztályokat, interfészeket. Ez a 
Webszolgáltatások egyre erősödő piacán nagyon fontos feladat, és 
talán ez is oka annak, hogy a World Wide Web konzorciumnál az 
XML Schema Definition (XSD) győzött, mint xml séma ajánlás. Ez 
nem jelenti azt, hogy a többi kihal, valószínűleg hosszabb távon 
a szabályalapúak közül is ki fog fejlődni egy jól használható leírás. 


Az XML Schema 

2001. május óta az XML Schema (XSD) az aktuális, a w3c által ja- 
vasolt sémaleírás. A formátum gyökerei a Microsoft XML Schema 
Reduced (XDR) sémához kötődnek, melyet (micsoda meglepetés) a 
Microsoft fejlesztett ki. Azért kellett az MS-nek az XDR-el bajlódni, 
mert a DTD kevés volt, végleges séma még nem volt a látóhatáron, 
így a korai xml támogatottságú termékekhez kellett egy fejlettebb 
sémaleíró nyelv. Az SOL Server 2000, az Internet Explorer 5.x, a 
Biztalk 2000, az Exchange 2000 mind-mind XDR-t használnak. 
Tavaly május óta van szabványos sémánk, így az SOLXML2-től 
már használhatjuk az XSD-t az SOL Server programozásához, az 
MSXML4 már XSD kompatibilis, valamint a .NET framework osztá- 
lyait már eleve úgy tervezték, hogy ismerjék az XSD-t is. Azaz 
mai fejlesztésekhez mindenképpen ez a megfelelő sémanyelv. 
Nézzünk most meg egy xml dokumentum példányt, majd írjunk 
hozzá sémát! 


€X?xml version-"1.0" encoding-"IS0-8859-2"?2 
£konyv isbn5-"D83b2l74be"2 
XxcimoxKutyavilág£/cim2 
$€szerzozCharles M. Schulzk/szerzo2z 
Kszereplo2 
Kxnev2Snoopy£/nev2 
Kbarat jazPeppermint PattyC/baratja?2 
Sszuletett21950-120-O4€/szuletett2 
gXjellemzeszextrovertált beaglek/ jellemzes2 
£/szereplo2 
Kszereplo2 
Xxnev2Peppermint PattyC/nev2 
$Sszuletett219bbh-08-22£/szuületett2 
cxjellemzeszkövér, vakmerő leányzóS/ jellemzes2 
£x/szereplo2 
€x/konyv2 


A séma megírásához egyszerűen végigmegyünk az összes ele- 
men, és definiáljuk őket. Előtte azonban az xsd:schema elemmel 
kell indítanunk: 


cX?xml versions"1.0" encoding-"IS0-8859-2"?2 
€xsd:schema 
xmlns:xsd-"http://www.w3.org/2002/XMLSchema"2 
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A schema elem a séma dokumentum gyökéreleme, 

amelyben az xsd prefixhez kötjük a séma aktuális 

névterét. Ennek az elemnek lesz még számos attri- 

bútuma, amely a teljes séma értelmezését befolyásol- 

ja, de erről egy kicsit később. 

A konyv elemünkhöz definiálnunk kell egy elemet, amelynek ne- 
ve konyv. Ennek az elemnek vannak gyermekelemei és attribú- 
tumai, ezért őt az xml sémában komplex típusnak tekintjük 
(complex type). A gyermekelemeket a seguence elemen belül 
definiálhatjuk: 


£Xxsd:element name-"konyv"2 
£xsd:complexType2 
£Kxsd:seguence2 


A seguence elem egy compositor, és azt írja elő, hogy a benne 
felsorolt gyermekelemeknek pontosan a megadott sorrendben 
kell szerepelni az xml dokumentumpéldányokban. További két 
compositor is van, a choice és az all. Ezekre még visszatérünk. 
Jöhet a cím és a szerző, ezeknek nincs gyermekeleme vagy att- 
ribútuma, így ők egyszerű típusok, simple type-ok. 


€xsd:element name-"cim" type-"xsd:Sstring"/2 
£xsd:element name-"szerzo" type-"xsd:string"/2 


A type attribútumban írjuk elő az egyszerű típusok adattípusát. 
Az xsd prefix azt jelzi, hogy a séma szabványban definiált string 
típust szeretnénk használni. 

A szereplo elem egy kicsit huncutabb, mert abból minimum egy, 
maximum akárhány darab is lehet. Mivel vannak gyermekelemei, 
egyértelmű, hogy komplex típus lesz, a számosságot pedig a 
elemdefinícióban tudjuk jelezni: 


€xsd:element name-"szereplo" 
minOccurs-"1" maxOccurs-"unbounded"2 
£xsd:complexType2? 
£xsd:seguence?2 


A minOccurs írja elő legalább hány példány kell az elemből, a 
maxOccurs pedig hogy legfeljebb mennyi. Az unbounded a vég- 
telent jelöli. Mindkettő alapértelmezett értéke 1, azaz ha nem ír- 
juk ki őket pontosan egy elemet kell a jelzett helyen találnunk. 
Ezek után jöhetnek a gyermekelemek: 


£Kxsd:element name-"nev" type-"xsd:Sstring"/2 
€xsd:element name-"baratja" type-"xsd:string" 
minOccurs-"0" maxOccurs-"unbounded"/2 
£Kxsd:element name-"szuletett" type-"xsd:date"/2 
£XKxsd:element name-" jellemzes" 
typez"xsd:string"/2 


Látható, hogy egy szereplőnek több (vagy akár semennyi) barát- 
ja is lehet, amit nem lehetett kiolvasni az xml mintánkból, ezt 
csak az tudhatja, aki ismeri az adatok logikáját, és ezért kell a 
séma egy mintapélda helyett. 

A szuletett elem típusa xsd:date, azaz ebben az elemben csak 
érvényes dátumokat reprezentáló sztringeket lehet megadni. 

A szereplo leírás kész, zárjuk le a megkezdett elemeket 


£/xsd:seguence2 


£/xsd:complexType2 
£/xsd:element2 £K!-- szereplo --2 
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A konyvben található gyermekelemek leírása is kész, 
zárhatjuk a sort: 


£X/xsd:seguence2 


Most jön az isbn attribútum. Az attribútumdeklarációknak köte- 
lezően a gyermekelemek után kell szerepelni. 


XKxsd:attribute name-"isbn" type-"xsd:string"/2 


Majd zárjuk a konyv elemet leíró komplex típust, magát az elem- 
deklarációt és a teljes sémát is: 


£/xsd:complexType2 
£/xsd:element2 
£/xsd:schema2 


Készen is vagyunk! Ez volt az ,orosz Matrjoska baba" tervezés, 
amelyben a séma írása közben pontosan követtük a leírandó do- 
kumentum szerkezetét. 


Az áttekintés kedvéért íme a teljes séma: 


£X?xml version-"1.0" encoding-"IS0-8859-2"?2 
£-- konyvsemal.xsd --2 
€xsd:schema 
xmlnsixsd-"http://www .w3.org/2001/XMLSchema"2 
Xxsd:element name-"konyv"? 
Xxsd:complexType2 
£xsd:seguence2 
£Xxsd:element name-"cim" type-"xsd:Sstring"/2 
£Xxsd:element name-"szerzo" 
typesz"xsd:Sstring"/2 
£Xxsd:element name-"szereplo" 
minOccursz"1" maxOccurs-"unbounded"2 
£Xxsd:complexType2 
£xsd:seguence2 
£xsd:element name-"nev" 
types-"xsd:string"/2 
€Xxsd:element name-"baratja" 
typesz"xsd:string" min0Occursz"0" 
maxOccursz"unbounded" /2 
£xsd:element name-"szuletett" 
type-"xsd:date"/2 
£Xxsd:element name-" jellemzes" 
type-"xsd:string"/2 
£/xsd:seguence2 
£/xsd:complexType2 
£/xsd:element2? C!-- szereplo --2 
£/xsd:seguence2 
£xsd:attribute name-"isbn" 
type-"xsd:string"/2 
£/xsd:complexType2 
£€/xsd:element2 
€/xsd:schema2 


Második nekifutás - modularizálunk 

Az előző ,nekirugaszkodunk és egyszuszra megírjuk" módszer 
bonyolultabb struktúrák esetén gyorsan áttekinthetetlenné vál- 
hat, gyorsan túlnyúlik a jobb oldal a képernyőn. Ennél laposabb 
sémát hozhatunk létre, ha kihasználjuk, hogy az előre definiált 
elemekre hivatkozhatunk a struktúra kívánatos pontján. 
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Ebben a tervezési módszerben globálisan, a schema elem alatt 
felsorolunk minden elemet, attribútumot, és az összetett típu- 
sokban csak hivatkozunk (reference) a már deklarált tagokra: 


£x-- konyvsemag.xsd --2 

€xsd:schema ...2 
£Xx!1-- egyszerű típusok definíciója --2 
£Xxsd:element name-"cim" type-"xsd:Sstring"/2 


£Xxsd:element name-"szerzo" type-z"xsd:string"/2 





£xsd:element name-"nev" type-"xsd:string"/2 
£Xxsd:element name-"baratja" type-"xsd:string"/2 
Xxcxsd:element name-"szuletett" type-"xsd:date"/2 
€xsd:element name-" jellemzes" 

type-"xsd:string"/2 
Kxsd:attribute name-"isbn" type-"xsd:string"/2 
£X1!-- komplex típusok --2 
£xsd:element name-"szereplo"2 

£Xxsd:complexType? 

£xsd:seguence2 


£x!-- az egyszerű típusokra a ref attribútumon 
keresztül hivatkozunk --2 
£xsd:element ref-"nev"/2 
€X!-- a számosságot itt jelöljük ki, nem az 


elem definíciójánál --2 
£xsd:element ref-"baratja" 
minOccursz"0" maxOccursz"unbounded"/2 
£Xxsd:element ref-"szuletett"/2 
£Xxsd:element ref-" jellemzes"/2 
£/xsd:seguence2 
£/xsd:complexType2 
£/xsd:element2 
€Xxsd:element name-"konyv"? 
£xsd:complexType2 
£Xxsd:seguence?2 
€xsd:element ref-"cim"/2 
$£xsd:element ref-"szerzo"/2 
£Xxxsd:element ref-"szereplo" 
minOccurs-"1" maxOccursz"unbounded"/2 
£/xsd:seguence2 
£xsd:attribute ref-"isbn"/2 
£/xsd:complexType2 
£€/xsd:element?2 . 
£/xsd:schema2 


Ez az objektumorientált programozási elvekre emlékeztet, amely- 
ben kis építőkockákból (alaptípusok — egyszerű típusok) építünk 
fel nagyobb blokkokat (osztályok, struktúrák - összetett típusok). 
Felfoghatjuk úgy is, hogy felül létrehozzuk az elemek, attribútu- 
mok absztrakt leírását, a komplex típusokban pedig példányo- 
sítjuk őket, konkrét elfordulásokat hozunk létre belőlük. 


Típusos megközelítés 

A harmadik sémaépítési módszerünkben összetett és egyszerű 
adattípusokat definiálunk, és ezek felhasználásával építjük fel 
az elemeket és attribútumokat. 

A módszer hasonló lesz az előzőhöz, csak most nem kész elemeket és 
attribútumokat hozunk létre, hanem a típusdefiníciókat megnevezzük, 
és ezekre hivatkozunk az elemekben és attribútumokban. 

Eddig csak komplex típusokat használtunk, azonban az XSD lehető- 
séget biztosít egyszerű típusok definiálására is. Az egyszerű típusok 
őseit a sémában definiált alaptípusok adják. Összesen 44-en van- 
nak, az ábrán az anySimpleType leszármazottjai (ld. következő kép). 
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A beépített típusokból származtatjuk le saját egyszerű típusain- 
kat listagenerálással, megszorítással vagy unióképzéssel. 

A listagenerálással képzett típus az alaptípuspéldányok white- 
space-ekkel elválasztott listája. 


£Xxsd:simpleType name-"nevnapok"2 
£xsd:list itemType-"xs:date"2 
€/xsd:simpleType? 


Egyféle ennek megfelelő tartalom (a szóköz és az újsor is white- 
space): 


2002-03-22 2002-04-10 
2001-01-05 


Jóval gyakoribb a megszorítással képzett típus, amelyben az 
alaptípus érvényes értékeit korlátozzuk le. 


£Xxsd:simpleType name-"nevTipus"? 
£xsd:restriction base-"xsd:String"2 
Xxsd:maxLength value-"32"/52 
£/xsd:restriction2 
£/xsd:simpleType2 


Ebben a példában a netTipus névvel ellátott egyszerű típus a 
string séma alaptípusból származik megszorítással (restriction), 
ahol a szöveg hosszát legfeljebb 32 karakterre korlátoztuk le. 








normalizedString integer 
token nonPozítivelnteger 10ng nonNegativelnteger 


language name NIITOKEN negatívelnteger int unsignedlong pozitivelnteger 


NCname NHTOKENS short unsignedint 





ID IDREF ENTITY byte unsignedShort 


IDREFS ENTITIES unsígnedByte 


II ér tipusok 


beépített egyszerű típusok megszorítással származtatott 


beépített származtatott típusok ——— listagenerélással származtatott 


összetett típusok 





kibővítéssel vagy megszorítással 


származtatott 


a Az XML Schema típusdefiníció hierarchiája 


A megszorításokat előre definiált facetekkel írhatjuk le, ilyen 
volt a maxLength is. Az alábbi táblázatban összefoglaltam a 
többi facetet is. 


Facet Jelentés 

length Az adott adattípuson értelmezhető alap- 
egységek száma. Például egy string ese- 
tén a karakterek száma. 


minLength Minimális hossz. 
maxLength Maximális hossz. 
pattern Reguláris kifejezéssel megfogalmazott 


kötöttség, amellyel az adott típus szöve- 
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enumeration Az alaptípus értékeit korlá- 
tozza le egy véges halmazra. 
maxInclusive Felső határ, beleértve a meg- 
adott értéket is. 
maxExclusive Felső határ, a megadott értéket 
már kizárva. 
minlnclusive Alsó határ, beleértve a megadott értéket is. 
minExclusive Alsó határ, a megadott értéket már 
kizárva. 
totalDigits Egy decimális típusból leszármazott típus 
számjegyeinek maximális száma (egész -- 
törtrész). 
fractionDigits Egy decimális típusból leszármazott 


típus törtrészében a számjegyek maxi- 
mális száma. 


A könyvek isbn számai pontosan tíz decimális számjegyből áll- 
nak, ezt az alábbi módon lehet megfogalmazni a pattern facet 
és benne reguláris kifejezések használatával: 


£xsd:simpleType name-"isbnTipus"2 
£€xsd:restriction base-"xsd:string"? 
£xsd:pattern value-"[0-3]( 20) "/2 
£/xsd:restriction2 
£/xsd:simpleType? 


Az enumeration típusra egy példa: 


£Xxsd:simpleType name-"szin"2 
£xsd:restriction base-"xsd:Sstring"? 
£xsd:enumeration valuez"barna"/2 
£xsd:enumeration value-"fekete"/2 
£xsd:enumeration value-"szoke"/2 
£/xsd:restriction2 
£/xsd:simpleType2 


Az unióképzéssel létrehozott típusok alaptípusok és/vagy 
általunk definiált egyszerű típusok összessége: 


£xs:simpleType name-z"variant"2 


£xs:union memberTypes-z"xsd:float xsd:integer 
xsd:String xsd:dateTime xsd:boolean xsd:long "/2 


£/xs:simpleType2 


Az így létrehozott típusunk erősen emlékeztet a Visual Basic 
variant típusára, ami sokféle adattípust képes leírni. 


folytatjuk... 
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ee 


Manager nem az 


hanem az AD-hoz 


) Az Exchange 
Server felügyelete 


Ismerkedjünk meg az Exchange 2000 felügyeleti eszközeivel, valamint nézzük meg az 
Active Directory Users and Computers snap-inbe integrált Exchange varázslókat! 


Mire érdemes még odafigyelni a telepítésnél? 
Ha Kedves Olvasóink elmélyedtek a ForestPrep és DomainPrep 
Exchange telepítési lépések rejtelmeiben, a kiszolgáló telepíté- 
se már gyerekjátéknak tűnik. Mire figyeljünk mégis oda? Hogy 
legyen elég helyünk a telepítéshez, illetve a kiszolgáló legalább 
a minimális követelményeknek megfeleljen. 
"? Legyen legalább 256MB RAM a gépben, és a page file legyen 
legalább kétszer akkora, mint a RAM tényleges mennyisége. 
"0 NTFS partícióra telepítsük az Exchange minden részét 
"0 Ami a helyfoglalást illeti, az Exchange - bárhová is telepítjük 
a kiszolgálón - a rendszerpartíción 200OMB körüli helyet 
felemészt. 
Ideális, ha a Exchsrvr könyvtár nem a rendszerpartícióra kerül, 
hanem attól külön, lehetőleg hibatűrő lemezekre. A mini- 
mális hely, amivel érdemes elindulni kb. 500 MB. 
Van még egy dolog, amit a telepítés előtt érdemes megfontolni, 
ez pedig az Exchange számára a rendszerfelügyeleti környezet 
(Administrative Groups) kialakítása. Az Administrative Groups ar- 
ra való, hogy az Exchange kiszolgálókat üzemeltetési, felügyeleti, 
és bizonyos beállítások szempontból csoportosítsuk. Az első 
Exchange 2000 telepítésénél nem tudjuk megadni, hová is kerül- 
jön az Exchange kiszolgáló, automatikusan a First Administrative 
Group nevű csoportba kerül. 
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Az Ezt megelőzhetjük úgy, ha az 
első kiszolgáló telepítése előtt 
Exchange System a forestprep után - az 


Exchange CD-ről felrakjuk az 
Exchange Exchange 2000 System Mana- 

A sát e ger-t, és ott létrehozzuk a meg- 
kiszolgálóhoz, felelő nevű Administrative 
Group-ot, majd csak ezután te- 
lepítjük az első Exchange 
2000-et. Egy AD erdőben több 
Administrative Group-ot lehet 
létrehozni, de a kiszolgálókat utólag nem tudjuk az egyik csoport- 
ból a másikba átrakni. Sajnos. 


csatlakozik! 


Az Exchange rendszergazda eszközei 

Mielőtt nekiesnénk felhasználókat, nyilvános mappákat létre- 
hozni, áttekintjük az Exchange beállításához és a mindennapi 
Exchange adminisztrációs feladatokhoz használatos programo- 
kat. Megnézzük, melyik eszköz mire is való tulajdonképpen, mit 
és hol találhatunk bennük. Lehet, hogy sokan ezt feleslegesnek 
érzik, mert úgy gondolják, a gyakorlat teszi a mestert, azonban 
nem árt tudni mit, hol és miért ott találjuk. 

Az Exchange előző verzióinál nagyjából egyetlen grafikus inter- 
fésszel bíró eszköz, és pár parancssori segédprogram volt, ami- 
vel az Exchange összes nyűgjét lehetett orvosolni. Ez a helyzet 
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megváltozott, ami főként az Exchange és az Active Directory 
igen bensőséges kapcsolatából adódik. Egy dologban a legtöbb 
Exchange 2000 eszköz megegyezik: mindegyik egy-egy MMC mo- 
dul - természetesen a parancssori programok kivételével. 


A System Manager 

A Start menüben ugyan ezen a néven találkozhatunk vele, de az 
MMC modul neve Exchange System. Nagyon fontos tudnunk, 
hogy ez az eszköz az Active Directoryban matat, annak is a 
Ha elindítjuk a Start Menüből, akkor az első, útjába akadó tar- 
tományvezérlőhöz próbál csatlakozni, azaz az ugyanazon az alhá- 
lózaton (subneten) levő tartományvezérlőt keres; ha ilyet nem ta- 
lál, akkor a saját telephelyen (Site) levő tartományvezérlőhöz pró- 
bál csatlakozni. Az Exchange System Manager nem az Exchange ki- 
szolgálóhoz, hanem az AD-hoz csatlakozik! Értelemszerűen, ha az 
Exchange kiszolgáló egyben tartományvezérlő is, akkor ahhoz kap- 
csolódik, de ez nem jelent semmit, hisz az AD-ból fogja lekérdez- 
ni az Exchange beállításokat. Ha valaki meg szeretné határozni 
pontosan, hogy a System Manager melyik tartományvezérlőhöz 
csatlakozzon, akkor indítsa el az MMC-t a Futtatás (Run) panelből, 
majd adja hozzá az Exchange System modult az MMC konzolhoz. A 
folyamat során az egyik ablakban meg lehet adni a tartományve- 
zérlő nevét, amihez azután majd csatlakozik a modul. 
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5 A System Manager alapértelmezett nézete 


Eltérő lehet, hogy mit is látunk itt sorban, attól függően, hogy 
az Exchange adminisztrációs csoportokat láthatóvá tesszük vagy 
sem. Ha a legfelsőbb objektum tulajdonságait előhúzzuk, ott be 
tudjuk állítani a nézetet, azaz hogy látszódjanak-e az admi- 
nisztrációs és útválasztó csoportok, vagy sem. 
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5 Administrative Group-os nézet 


A második nézetben annyit változik a helyzet, hogy a beállítások 
más csoportosításban jelennek meg, vagyis az egy adminisztrációs 
egységhez tartozó beállításokat egy helyre gyűjti össze. Ha a ké- 
pen lenne több ilyen csoport, akkor azalatt is ezeket a pontokat 
látnánk. Ennek a nézetnek igazán csak akkor van értelme, ha több 
ilyen adminisztrációs csoport létezik egy szervezeten belül. 


A System Manager menürendszere 
A Szervezet ikonja - a legmagasabb szintű objektum a System 
Managerben. Ha ennek a tulajdonságablakát előhúzzuk (Jobb 
klikk - Properties) , ezt látjuk: 
BIE 
General ] Detais [Security ] 
8 e 
( Administrative views: 
Configure whether your organization employs routing groups and 
administrative groups. 
I [Bisplag rouiing groupz 
TT Digplay administrative groups 





Operation mode: 
Mixed Mode (can suppott pre-Exchange 2000 Servers) 

[7 Change operation mode————————————————————— 
The change to natíve mode can not be reversed. 


Change Mode 

















Cancel Épp. Help 


Tehát itt állíthajuk be a System Manager nézetét, erről már volt 
szó, valamint az Exchange üzemmódját, abból a szempontból, 
hogy képes-e együttélni korábbi verziójú Exchange kiszolgálók- 
kal, vagy sem. Ez más mint a Windows 2000 Active Directory 
üzemmódja, abban azonban hasonlítnak, hogy a változtatás itt 
is csak egyirányú lehet: ha egyszer feladjuk az együttélés lehe- 
tőségét és átváltunk úgynevezett natív módra, nincs visszaút. 

A képen látszik a Security fül is, ami alapértelmezésben nincs 
ott. Általában nem is szükséges, de vannak helyzetek amikor 
hasznos lehet, azonban ezzel óvatosan kell bánni, mert amit itt 
beállítunk, öröklődni fog az exchange összes objektumára. Ah- 
hoz hogy megjelenjen a Security fül tegyük be a ShowSecurity- 
Page-1 értéket DWORD típusban a következű registry kulcs alá: 


HKEY. CURRENT. USERNSoftwareWficrosoftN 
S ExchangeVEXAdmin 
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Egyébként az ADSI Editet használhatjuk a szerveze- 
ti szintű jogosultságok beállítására. Az Exchange 
jogosultságai izgalmas téma, külön cikket szente- 
lünk neki, ezért most nem szólnék többet erről, néz- 
zük inkább tovább a System Managert. 


Global settings - a nevében is benne van, itt a teljes szerveze- 
tet érintő beállításokat találjuk. Itt (is) meg lehet határozni a 
be és kimenő levelek méretét. Jó tudni azonban, ha a bejövő le- 
velek méretéhez beállítunk korlátozást, az még nem garantálja, 
hogy a túlméretezett levelek nem fognak bejutni. Ugyanis ha a 
küldő fél nem veszi tudomásul ezt a beállítást, akkor bizony be 
fognak esni a nagyméretű levelek is. A Global Settings alatt ta- 
lálható még a kimenő levélformátumok beállításai is, valamint 
itt tudjunk szabályozni, hogy mely e-mail címekről ne jöhessenek 
be levelek. 


Recipients - itt találhatóak a postafiókokhoz kapcsolódva a 
címlisták beállításai, a postafiókokhoz rendelhető szabályok, 
például az e-mail címek. Ezekről egy későbbi cikkben lesz szó 
részletesen. 


Servers - itt találhatóak az Exchange kiszolgálókhoz közvetle- 
nül rendelhető beállítási lehetőségek, kommunikációs protokol- 
lok, valamint az Exchange adatbázisok beállításai. 


Routing Groups - egy routing csoportba tartoznak azok az 
Exchange kiszolgálók, amelyek megbízható kapcsolattal rendel- 
keznek, pl. egy helyi hálózaton vannak. Egy szervezetben több 
routing csoport is lehet, de egy kiszolgáló egyszerre csak egy- 
ben szerepelhet. Itt lehet beállítani a különböző csatolókat 
(Connectors) más üzenetkezelő rendszerek felé. 


Folders - itt találjuk a különböző ún. tárolócsoportokhoz tarto- 
zó adatbázisokat. Ugyanaz lelhető itt is fel mint a kiszolgálói 
objektumok alatt, csak más csoportosításban. 


Tools - ide tartozik az Exchange 5.5-ről való áttérésnél haszná- 
latos replikációs szolgáltatás, valamint innen meghívható egy 
MMC modul, ahol az üzenetek nyomonkövetését lehet beállítani. 


Végignéztük az összes menüpontot, és mégsem leltük a felhaszná- 
lói postafiókok beállításait. Persze hogy nem, mert azok az Active 
Directory Users and Computersben találhatóak. Újabb bizonyítéka 
annak, hogy nincs Exchange 2000 Active Directory nélkül. Mielőtt 
azonban rátérnék a felhasználók dolgaira, kitérőt teszünk, és meg- 
nézzük az Exchange beállításait egy másfajta nézetből. 


ADSI Edit - AD Service Interface Editor 

Fontosság szempontjából a rendszergazdai eszközök sorában talán 
a harmadik az ADSI Edit, amellyel hogy úgy mondjam , hátulról" 
láthatjuk ez Exchange összes beállítását. Sőt, nemcsak az Exchange 
beállításokat láthatjuk, hanem az Active Directoryban fellelhető 
összes objektumot. Leginkább az előző verziós Exchange 
Administrator RAW módjához lehetne hasonlítani az ADSIEdit hasz- 
nálatát az Exchange 2000 vonatkozásában. 

Az ADSIEdit a Windows 2000 Support Tools része. Ahhoz hogy 
használni tudjuk, elegendő a Windows 2000 Server CD-ről 
SupportWools könyvtárból a support.cab fájlból az adsiedit.dll-t 
kimásolni mondjuk a "osystemrootyolsystem32 könyvtárba és 
regsvr32 adsiedit.dil parancsot kiadva regisztrálni a dll-t. Ezután 
MMC modulként hozzá tudjuk adni a konzolhoz. Az ADSI Edit szin- 
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tén NEM az Exchange kiszolgálóhoz csatlakozik közvet- 
lenül, hanem a legközelebbi, vagy egy meghatározott 
tartományvezérlőhöz. 
Az Exchange konfigurációs beállításait az Active 
Directory konfigurációs konténerében  (Configuration 
Container) a CN-Configuration - CN-Services - CN-Microsoft 
Exchange alatt találhatjuk. Ezen belül van - ahogy az alábbi ké- 
pen is - az Exchange szervezet (Organization), és természetesen 
a beállítások, amiket normális esetben az Exchange System 
Managerből állítgatunk. Biztonsági beállításokat is lehet ilyen 
módon állítani, alapértelmezésben a Organization és az 
Administrative Groups szintjén csak itt lehet állítani a jogosult- 
ságokat, de azt már láttuk a cikk elején is, hogy ez kikerülhető. 


I Sonsole Window Help 
] aron Yew [[ 5 [Elmie BBIe ] 
tree CNszohel 7 Object(5) 
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5 Exchange beállítások az ADSI Editben 


Számos esetet lehetne itt most felsorolni, hogy mikor használatos 
az ADSI Edit a beállításokhoz, általában akkor húzzuk elő, ha nincs 
mód, hogy pl. a System Managerből vagy az Active Directory Users 
and Computerből állítsunk be valamit. Például mindenki képes ún. 
top level nyilvános mappát létrehozni, amit úgy is meg tudunk 
akadályozni, illetve szabályozni, ha a CN-Microsoft Exchange - 
CN-cszervezeti név: tulajdonságait előhúzva, a Security fülön az 
Everyone csoporttól megvonjuk a Create top level public folder jo- 
got, illetve a megfelelő csoporthoz hozzárendeljük. 


Active Directory Users and Computers 

Egy másik igen fontos eszköz az AD Users and Computers MMC 
modul, hisz ez használatos az Exchange felhasználók, a disztri- 
búciós listák és a kapcsolatok (Contacts) karbantartására is. 
Kétféle felhasználó lehet az Exchange-ben. Az egyik, akinek az 
Active Directoryban felhasználói neve, postaládája és e-mail cí- 
me is van, ezt hívjuk mailbox-enabled felhasználónak. A másik, 
akinek szintén van az AD-ban felhasználói neve, de nincs pos- 
taládája a helyi Exchange rendszerben, hanem egy külső e-mail 
címmel rendelkezik (így szerepel a címlistákban is): ő a mail- 
enabled felhasználó. 

Kétféleképpen is létrehozhatunk Mailbox-enabled felhasználót: 
ha nincs a felhasználónak azonosítója a tartományban, akkor 
egy menetben létrehozhatjuk a felhasználói accountot és a pos- 
taládát is, ilyenkor a szokásos felhasználó létrehozásához szük- 
séges kérdések után jön ez az ablak: 
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E szan tám 


7 Cieate an Exchange malbox 





5 Gipsz Jakab mailbox-enabled felhasználó létrehozása 


Meg lehet adni, hogy mely adminisztrációs egységbe tartozó, 
azon belül is melyik Exchange kiszolgálón és melyik adatbázis- 
csoportba szeretnénk rakni a postaládáját. 

Ha már az AD-ban létező felhasználónak szeretnénk létrehozni 
postaládát, akkor az Exchange Task Wizardot, vagyis Exchange 
Feladatvarázslóját lehet segítségül hívni, a felhasználói objek- 
tumon jobb klikk - Exchange Tasks...-ra kattintva. 

A varázsló mindig csak az adott objektumhoz (felhasználó/cso- 
port/kapcsolat) illetve a környezetben végrehajtható változtatások- 
hoz ajánl fel lehetőségeket. Például egy olyan felhasználónál. akinek 
nincs postaládája még az Exchange-ben, a következőket ajánlja fel: 


Exchange Task Wizard Bé 


Awvailable Tasks 
The following is a list of tasks that can be appked to one or more of the selected 
objects. Select the desired task and press Next. 








Select a task to perform: 








5 Helyzetérzékeny varázsló 1. 


Az Enable Instant Messaging azért szerepel, mert fel van telepít- 
ve az a komponens is; ha nem volna, akkor nem szerepelne itt. 
Move mailbox feladat azért nem szerepel, mert még nincs mit 
mozgatni, hisz csak most szándékozzuk létrehozni a postaládát. 
Ha egy létező, postaládával rendelkező felhasználónál húzzuk 
elő a varázslót, akkor ezeket látjuk: 


Exchange Task Wizard ; 24 


Available Tasks 
The following is a list of tasks that can be appfed to one or more of the selected 
objects. Select the desíred task and press Next. 











5 Helyzetérzékeny varázsló 2. 


Ha csak mail-enabled felhasználót vagy kapcsolatot szeretnénk 
létrehozni, akkor használatos az Establish e-mail address feladat. 
Mail-enabled felhasználót nem tudunk egy menetben létrehozni, 
mert a felhasználó létrehozásánál a postaládára kérdez rá a varázs- 
ló, ezért először létre kell hozni egy , natúr" felhasználót az AD- 
ban, és utána lehet e-mail címmel ellátni, így lesz mail-enabled. 
A mail-enabled felhasználó nem összekeverendő a Kapcsolat 
(Contact) objektummal, ugyanis az utóbbinak nincs az AD-ban 
felhasználó azonosítója, így Exchange postaládája sincs, csupán 
egy külső e-mail címmel rendelkező objektum az AD-ban, amely- 
nek címe látható a címlistában. 

Természetesen ha egy új Kapcsolatot hozunk létre (az adott 0U- 
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ban jobb klikk - New - Contact) akkor a varázsló rákérdez, hogy 
szeretnénk-e e-mail címet hozzárendelni, majd kell választani 
egy e-mail cím típust (például SMTP, Notes, GroupWise, cc:Mail, 
vagy X.400). Meg kell adni a típusnak megfelelő e-mail címet, 
sőt be lehet állítani a feljövő ablak Advanced fülén, hogy mi- 
lyen formában menjen a levél az adott címre. (MIME vagy UU- 
Encode/Plain Text formátumban.) 

Nemcsak felhasználóknak, hanem csoportoknak is lehet e-mail cí- 
me. Az AD-ban kétféle csoport létezik a biztonság szempontjá- 
ból. A biztonsági v. Security csoportokhoz jogosultságok is ren- 
delhetők, míg a disztribúciós csoportok csak üzenetek szétosz- 
tására valók. Az Exchange szempontjából mindegy, hogy milyen 
csoportról van szó, legyen az biztonsági vagy disztribúciós, ha 


Új beállítunk nekik e-mail 
Meg kell adni címet, azaz mail-enab- 
a típusnak megfelelő led csoportokká tesszük 


taki vő őket, akkor megjelen- 
e-mail címet, sőt De nek a címlistákban, a 


lehet állítani a feljövő csoport címére küldött 

leveleket a csoport min- 

ablak Advanced — 44 olyan tagja meg- 

fülén, hogy milyen — kapja, akinek van e- 
formában menjen 


mail címe. 
Csoport esetén egysze- 
a levél az adott címre. rűbb az Establish e-mail 
(MIME vagy address varázsló, ott nem 
ú kérdez e-mail címet, csak 
UUEncode/Plain Text égy Alastikér, ami a 6 


formátumban) előtt fog szerepelni az e- 


mail címben, a többit át- 
veszi a központi beállításoktól. 
Csoportok esetén értelmezett a Hide és Unhide Group membership 
feladat, ami értelemszerűen vagy eltünteni a kíváncsiskodók sze- 
me elől, hogy kik tartoznak egy adott csoportba, vagy láthatóvá 
teszi azt. Alapértelmezésben láthatóak a csoporttagságok. Ez a va- 
rázsló nem tesz mást, mint az Everyone csoportnak explicite tiltja 
vagy visszaadja a Read jogát az adott csoportra vonatkozóan. 
A teljesség kedvéért jegyzem meg, hogy e-mail címe ezeken kí- 
vül lehet a nyilvános mappáknak is, amit az Exchange System 
Managerben lehet állítani. Részletesen erről majd a nyilvános 
mappákról szóló cikkben szólunk. 


Felhasználói tulajdonságok 
Egy postaládával rendelkező felhasználó tulajdonságablakai így 
néznek ki első megközelítésben: 





Working úith 


wvindővs 2 





Jakab Gipsz Properties 212 


MemberOf ] Dian ] Environment ] Sessions ] Remote control ] 
Terminal Services Profde Exchange General ] 
E-mal Addresses Exchange Features ] 
General ] Address ] Account ] Profie ] Telephones ] Organization ] 


e Jakab Gipsz 


5 Egyszerűbb nézet 
Ugyanennek a felhasználónak a tulajdonságablakai így is ki- 
nézhetnek: 
213 
Publshed Certificates ]  MemberOf ] Diatmn ] Object ] Security ] 
Environment ] Sessions ] Remote control ] Terminal Services Profde. ] 
Exchange General 1 E-mad Addresses ] 
Exchange Features l Exchange Advanced 
General ] Addresz ] Account ] Profte ] Telephones ]) Organization ] 


e Jakab Gipsz 


0 Mintha több lehetőség lenne itt 


Nem árulok el nagy titkot, ha azt mondom, ez azért van, mert az 
Active Directory Users and Computers konzol nézetét átállítottam. 


ctory Users and Computers 


console Window  tHep 














5 Az Advanced Features nézet ki és bekapcsolása 

Nem csak a felhasználóknál sokasodik meg az elérhető beállítá- 
sok száma ilyenkor, hanem minden objektumon, valamint meg- 
jelennek extra konténerek is, amelyek addig rejtve voltak. 


Folytatás következik a felhasználók beállításaival... 


Dorner Csilla 
MCSE 


SNS. 04: 
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Asz A Web Storage System 
98 Programozott levélkezelés 


Exchange sorozatunkhoz kapcsolódóan néhány cikk erejéig betekintünk a 
Web Storage System programozott elérésébe. Legelőször az ADO-n 
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A Web Storage System (WSS) az Exchange2000 Server új adat- 
tárolási mechanizmusa. Hatalmas előnye, hogy sokoldalú hozzá- 
férést biztosít az adatokhoz (HTTP, SMTP, IMAP4, POP3). Egyet- 
len szerveren egymástól függetlenül, méreteikre vonatkozó kor- 
látozás nélkül több store is elhelyezkedhet (nyilván a rendelke- 
zésre álló tárterület határain belül...). A WSS felépítése hierar- 
chikus: a különböző fájlok, dokumentumok  mappákba 
szervezhetők, s ezek a mappák (folderek) tetszőleges mélységig 
egymásba ágyazhatók. E-maileket, szövegfájlokat, Office doku- 
mentumokat, multimédiás fájlokat stb. egyaránt tárolhatunk a 
WSS-ben ugyanúgy, mint egy egyszerű fájlrendszerben. 


E Béla 


Inbox 
LL Hello bela.eml 








Contact 













Publis folders 



















Pénztárkönyv 
Public LL" Pénztár .xls 
Store ff éb 
Prezentációk 
LD A cégem.ppt 

















6 A Web Storage System felépítése 


Alapvetően két store típust különböztetünk meg: a Mailbox 
store-t és a Public store-t. 

A Mailbox store olyan adatbázis, amelynek mappáihoz és doku- 
mentumaihoz egyetlen felhasználó, a tulajdonos fér hozzá. E- 
maileket, hozzájuk csatolt állományokat, mappákat, dokumen- 
tumokat stb. tárolhatunk itt. Természetesen minden felhaszná- 
lóhoz külön Mailbox store rendelhető. 

A Public store legfőképpen abban különbözik a Mailbox store- 
tól, hogy nem egyetlen felhasználó kizárólagos tulajdona, meg- 
osztottan többen is hozzáférhetnek - persze a megfelelő jogo- 
sultságok alapján. 


Keresés a WSS-ben 

A WSS a keresést a leggyakrabban használt sémajellemzők 
(schema property) indexelésével optimalizálja. Ezek a mezők: 
Subject, Body, From és To. A WSS-t egyszerű SOL szintaxissal is 
elérhetjük, erről később, az ADO részben írok. Ezenkívül a tarta- 
lom szerinti indexelés (content indexing) és a full text keresés 
is támogatott, jelentős sebességnövekedéssel örvendeztetve 
meg a felhasználót. Mindez beépített lehetőség, nem igényel 
külön szoftvert, kódolást, álmatlanul töltött programozói éjsza- 
kákat. Mindezeket figyelembe véve elmondhatjuk, hogy a koráb- 
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keresztüli hozzáférést vizsgáljuk meg. 


bi verziók keresési lehetőségei jelentősen javultak. 

Nagyon hasznosak az úgynevezett keresőmappák (search folder). 
Ezek olyan mappái a WSS-nek, amelyek korábbi keresések ered- 
ményeit tárolják, s később bármikor hozzáférhetőek. 


A továbbiakban arra koncentrálunk, hogy saját kódból, programo- 
zott módon milyen lehetőségeink vannak a Web Storage System 
elérésére. 


A WSS elérése ADO-val 

Az alábbi ábra azt mutatja, hogy a Web Storage System hogyan 

érhető el ADO-n (illetve CDO-n) keresztül: 

] Az ExXOLEDB provider kiszolgálóoldali kom- 

úi ponens, melyen keresztül - egy COM vagy 
COM-4- objektumba ágyazva, ASP-vel vagy 
más webalkalmazással - elérhetjük a kiszol- 
gálón lévő adatokat. Ily módon akár a he- 

















ADO ] CDO 

OLE DB lyi, akár távoli tárolók is elérhetőek. 
ExOLEDB A következő forrásrészlet azt mutatja, hogy 
Provider hogyan férhetünk hozzá a WSS állományai- 


hoz a RecordSet objektum segítségével: 


L 
v 


Exchange 
káli 5 A WSS elérése ADO-val vagy CDO-val 


Set conn - Create0bject("ADODB.Connection") 
conn.Provider - "ExOLEDB.DataSource" 
conn.Open "http://myserver/folder/" 

Set rs - CreateObject("ADODB.Recordset") 
strSAL - "SELECT ""DAV:displayname"" , 

GW "DAV:contentclass"" " 8 

"FROM ""http://myserver/folder/"" " 8 
"UHERE ""DAV:ishidden"" zs FALSE " 8. 
"AND ""DAV:contentclass"" - 

4 "urn:content-classes:message" " 

rs.Open strSAL, conn 


Létrehozzuk a connection objektumot, melyhez kijelöljük az 
ExXOLEDB providert, és megnyitjuk a megfelelő kiszolgálóra. Ezzel 
létrejött a kapcsolat az Exchange Server megfelelő mappájával. 

A CreateObject parancs segítségével létrehozunk egy RecordSet- 
et, majd egy egyszerű stringváltozóba betöltjük a lekérdezésnek 
megfelelő SOL mondatot. Azért éppen SOL, mert az ExOLEDB 
Provider ezt a szintaxist használja a WSS ADO-n keresztüli eléré- 
sére (bővebben lásd az Exchange SDK-ban). A WSS jellemzőit 
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különböző névterekbe sorolva találhatjuk, ezek közül egy az álta- 
lunk használt DAV:, amely a leggyakrabban használt jellemzőket 
tartalmazza. Néhány további névtér, a teljesség igénye nélkül: 


Névtér Leírás 

urn:schemas:calendar Naptárhoz rendelt jellemzők, 
például találkozó, évforduló stb. 

urn:schemas:contacts Egyénekhez rendelt jellemzők, 

például csoport, vagy szervezet neve 

Az üzenetek törzsének leírására 

szolgáló jellemzők. 

Az üzenetek fejrészének 


urn:schemas:httpmail 


urn:schemas:mailheader 
leírására szolgáló jellemzők 
http://schemas.microsoft.com/ 
texchange Exchangespecifikus jellemzők. 
Természetesen lehetőség van saját névterek definiálására is, például 
létrehozhatunk http://schemas.cégnév.hu/belso névteret, hogy az 
általunk újonnan felvett jellemzőket ott tároljuk. Erre olyankor lehet 
szükség, ha olyan leírókat kívánunk használni, amelyek eredetileg 
nincsenek a WSS-ben, például az alkalmazottaink fényképét, vagy 
gyermekeinek adatait, stb. is el kívánjuk tárolni a WSS-ben. 


A fenti lekérdezés alapján az rs.Open parancs kiadásával vissza- 
kapjuk azokat a WSS-ben tárolt dokumentumokat, amelyek megfe- 
lelnek az általunk kiadott kritériumoknak. Példánkban a DAV: név- 
tér displayname és contentclass jellemzőit (property) szeretnénk 
elérni azon e-mailek (DAV:content-class- urn:content-classes: mes- 
sage"?) esetében, amelyek nem rejtettek (DAV:ishidden -FALSE). A 
message értéken kívül a content-class felveheti még appointment, 
person, item, calendarmessage stb. értékeket is, az urn:content- 
classes névtérből. 

Jól látható, hogy a WSS-ben minden a jellemzőkön keresztül 
érhető el, ezek alapján szűrhetünk, kereshetünk, rendezhetünk, 
stb. Nagy előnye ennek a tárolásmódnak, hogy teljesen dinamikus, 
tehát, ha egy propertyhez nem rendelünk értéket, akkor az nem is 
jön létre. Viszont amint feltöltjük valamivel, az Exchange2000 el- 
végzi a helyfoglalást, létrehozza, stb. Természetesen ha kitöröljük 
az értékét, azonnal megszűnik a property létezése is. 

Ezek után lássuk, hogyan listázhatjuk ki egy adott dokumentum 
jellemzőit: 


rs.Move sorszam 
Dim fld 
for each fld in rs.Fields 


Response.Write (fld.name 8 " — " a 
GWfld.value § VbCrLf) 
next 


Az első sorban a RecordSet megfelelő elemére visszük a kurzort 
(feltételezzük, hogy a sorszam nevű változó egy olyan egész típu- 
sú értéket tárol, amely ebben a környezetben értelmezhető) , majd 
egy for each ciklusban megyünk végig az elem minden egyes jel- 
lemzőjén, és kiíratjuk annak nevét és értékét. 

Ugyanezt az eredményt érhetjük el akkor is, ha már a végrehaj- 
tás legelején tudjuk, mely dokumentumra lesz szükségünk, és 
RecordSet helyett egyetlen Record-ot hozunk létre. Figyeljük 
meg, hogy ebben az esetben közvetlenül rámutatunk az 
Exchange szokásos WebDAV URL-ének segítségével egy adott le- 
vélre, és ez kerül be az ADODB.Record objektumba: 


Set conn - Create0bject( "ADODB. Connection") 
conn.Provider - "ExOLEDB.DataSource" 

conn.Open "http://myserver/folder/" 

Set rec - Createobject( "ADODB.Record") 

rec.Open "http://myserver/folder/level.eml", conn 


Ennyi volt a móka mára... 

És hogy mire jó mindez, azon kívül, hogy szép és jó, valamint 
számos átizzadt éjszakával képes megajándékozni azt, aki köze- 
lebbről is próbálja megismerni? A levelezésen, a levelek saját 
kódból történő kezelésén felül gyakorlatilag minden tárolható, 
kereshető, indexelhető, kezelhető a WSS-ben, így például céges 
nyilvántartásokat, adatbázisokat készíthetünk a dokumentá- 
ciókból, bemutatókból, levelezésekből, mindenből, melyhez sa- 
ját, az átlagos felhasználók számára is könnyen elsajátítható, 
használható, barátságos és a sokszínű igényeknek megfelelő ke- 
zelői felületet írhatunk. 


A következőkben a Web Storage System WebDAV-on, illetve a 
.NET-es WebReguest-en és WebResponse-on keresztül történő 
elérését ismertetem majd, hogy az új technológiák hívei is 
megismerhessék a Web Storage System rejtelmeit. 


Molnár Ágnes 
agnes.molnar odataware.debis.hu 


eset erd eg a GÁ UTTA 


[1] Exchange SDK (2002. március): 
http://msdn.microsoft.com/downloads/default.asp?url-/downloads/sample.asp?url- 
$/msdn-files/027/001/834/msdncompositedoc.xml 
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Adminisztráljunk Windows 2000-et ! 


. Windows XP Professional kliensről 


Hódít a Windows XP. Ön is lecserélte már saját munkaállomásán régi, 
Windows 2000 Professional operációs rendszerét ugye? Hogyan lehet XP-ről 
távfelügyelni a Windows 2000 kiszolgálókat? Terminal ablakból. És még? 


A Windows XP térhódításával egyre gyakoribb, hogy a klienseken 
XP, míg a szervergépen Windows 2000 van telepítve. Ekkor rögtön 
felvetődik az az igény, hogy az eddig megszokott módon távolról 
adminisztrálhassuk a szerver beállításait. 

Ezt megtehetjük Terminal Services segítségével, melyet Remote 
Administration módban telepítünk egy Windows 2000 Server operá- 
ciós rendszert futtatató gépre, ez azonban csak 2 kapcsolódást tesz 
lehetővé. Megoldás jelent a Windows .NET Server Administration 
Tool Pack (Adminpak.msi) béta verziójának telepítése is. 

Az Adminpak.msi önkicsomagoló fájl tartalmazza a leggyakrabban 
használt eszközöket, melyeket Windows 2000 és Windows .NET 
Server operációs rendszereket futtató szá- 


Az új ADMINPAK.MSI segítségével! 


ság hiányáról beszélhetünk mind a .NET Server eszközökkel történő 
Windows 2000 rendszer adminisztrálásakor, mind fordított esetben. 
A Windows .NET Server Administration Tools funkcióinak többsége 
lehet, hogy nem engedélyezett vagy támogatott, amikor Windows 
2000 operációs rendszerrel rendelkező számítógépet adminisztrá- 
lunk vele. Például a , saved guery for last logon time" funkció nem 
támogatott a Windows 2000 alapú számítógépeken, mivel ezt a 
parancsot a Windows 2000 Active Directory nem ismeri. A legtöbb 
esetben ezek a fejlettebb eszközök nem csak nem engedélyezet- 
tek, de nem is láthatók, amikor az adminisztrációs eszközöket 
Windows 2000 rendszerekre irányítjuk. 

A Windows .NET Server Adminpak nem te- 


mítógépek helyi és távoli adminisztráció- Manapság lepíthető Windows 2000-re, és nem is fut 
jára használhatunk hozzájuk kapcsolódó a Windows XP ezen az operációs rendszeren. Parancsori 
kliensekről. Professionalt eszközeit sem érdemes felmásolni, mivel 


Ha adott egy Windows 2000 operációs 
rendszerrel rendelkező gép (melyre koráb- 
ban Windows 2000 Adminpak.msi-t telepí- 
tettünk), s ezek után upgradeljük az 
oprendszert Windows XP-re vagy Win- 
dows .NET Serverre, a telepítés folyamán 
a rendszer figyelmeztet minket, hogy a 
Windows 2000 Administration Tools nem 
kompatibilis az új operációs rendszerrel: távolítsuk el, és használ- 
junk Terminal Services-t vagy telepítsük a Windows .NET Servers 
Adminpak béta verzióját. Ha mégsem távolítjuk el a fent említett 
eszközöket és megpróbáljuk őket használni, azt tapasztaljuk, hogy 
el sem indulnak, vagy nem működnek megfelelően. 

A Windows 2000 Adminpak.msi utólag nem telepíthető Windows 
XP kliensre: megmakacsolja magát. Manapság a Windows XP Pro- 
fessionalt futtató gépekre csak az Adminpak.msi Windows .NET 
Server Beta 3 verziója telepíthető. A Windows XP Professional saj- 
nos nem tartalmazza az előbb említett fájlt, mivel még nem volt 
elérhető az XP piacra kerülésekor. 

A Windows .NET Server adminisztációs eszközeinek többsége hason- 
lóan működik, mint amit a Windows 2000-ben megszoktunk. Néhány 
esetben azonban ezek az eszközök nagyobb funkcionalitással rendel- 
keznek, viszont bizonyos esetekben a kompatibilitás és támogatott- 
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Adminpak.msi 
Windows .NET Server 
Beta 3 
verziója telepíthető 
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Windows 2000 alatt azok sem működnek. 
A Windows .NET Server Adminpakot ki- 
mondottan Windows XP-re és Windows 
.NET Serverre tervezték. 

A Windows XP-k közül csak a Professio- 
nalra telepíthetjük a Windows .NET Server 
Adminpak.msi béta 3-as verzióját. Mivel a 
Windows XP Home Edition nem tud Win- 
dows NT 4.0-ra, Windows 2000-re vagy Windows .NET Serverre 
kapcsolódni, ezért ezen az operációs rendszeren nem is támoga- 
tott az adminpak telepítése. 

Ahhoz, hogy Windows XP Professionalunkra telepíthessük a fent 
említett adminpakot, elég ha az [1] címről letöltjük az adminpak- 
.exe fájl, amely egy önkitömörítő állomány, tartalmazza az Admin- 
pak-readme.txt és a B3-web-version-adminpak.msi fájlt. Telepítés- 
hez pedig elegendő, ha duplán kattintunk az .msi fájlra. 

Ne higyjük, hogy tökéletesen fognak működni a Windows .NET 
Server Administration eszközök, hisz még csak béta minőségűek. 
2002 folyamán várható a végleges verzió. Ekkor a béta 3-at szed- 
jük le gépünkről és telepítsük a végleges verziót. 


Borsi Katalin 
bobo(onetacademia.net 


A cikkben szereplő URL-ek: 
[11 http://msdownload.netacademia.net — 
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Egy átlagos kaliberű, komplett asztali számítógép ma megvásárol- 
ható mintegy 150 ezer Ft-ért. A legtöbb esetben - amikor egyálta- 
lán be van kapcsolva - szövegszerkesztésre, játékra, internetezésre 
stb. használjuk, miközben a merevlemeznek a legjobb esetben is 
csak a töredékét tudjuk értelmes adatokkal feltölteni. Bob Metcalfe 
(az Ethernet feltalálója) 909o-ra saccolja a parlagon hagyott hard- 
vererőforrások arányát. Nyugodtan higgyük el, és nyugodjunk bele, 
hogy 135 ezer Ft-ot kidobtunk az ablakon. Bár arra senkit sem bíz- 
tatok, hogy várjon rá, a világháló horizontján már felbukkant a 
megoldást hozó világgép: a World Wide Computer. 

Mivel ezt az írást a Scientific American [1] cikke inspirálta, hadd 
induljak el egy, éppen ennek a magazinnak több évvel ezelőtt 
megjelent, magyar kiadásában fellelhető érdekes cikke nyomán: 
kutatók számítógépes szimulációval kimutatták, hogy minél több 
demokratikus ország lesz a világban, annál kisebb egy háború ki- 
törésének valószínűsége. A demokratikus országok ugyanis két- és 
többoldalú szerződésekkel jótékony béklyóba kötik magukat... 

Mi a világgép? A válaszhoz vegyünk egy végtelenül leegyszerűsí- 
tett, négyszereplős világot: ÉN, a felhasználó, Ők, a többi felhasz- 
náló, a koordinációs szervezet (K) és a Profit Rt (P). Jelentkezem 
K-nál, hogy bérbeadnék tárhelyet (mert már 
csak 20 gigás winyót lehet venni, míg nekem 5- 
ös is elég lenne), és programok futtatását is 
engedélyezném (mivel legtöbbször úgyis csak 


rálok, miegymás, telepítek egy programot, 

amolyan ügynököt, amely leveszi a vállamról 

a gondot, és a gépemet érintő üzleteket nyélbe üti. Ők ugyanezt 
tették, teszik és fogják tenni. P látja, hogy ez jó, mert nem kell 
neki megvenni a böszme nagy kiszolgálókat, elég ha bérli az erő- 
forrásokat K-tól. Kész a világgép, jöhet az eksön! 

P egy alkalmazottja egy új rekordot akar beilleszteni a vállalati 
adatbázisba. A gépén lévő ügynök belekukkant a világgép elosz- 
tott adatbázisába, és kiszúr magának néhány online gépet, ame- 
lyeken van hely. ÉN is köztük vagyok, pénz áll a házhoz :-) P ügy- 
nöke a rekordból valamilyen algoritmus szerint több apró darabkát 
készít, és mindegyiket gondosan titkosítja, nehogy Ők bele tudja- 
nak nézni (ÉN persze sosem tennék ilyet) . Aztán felveszi a kapcso- 
latot az ÉN és az Ők ügynökeivel, és mindegyik darabkát eltárol- 
tatja velük (a biztonság kedvéért egy darabkát több gépen is). A 
virtuális számlámon jóváír egy adott összeget, és ekkor már ÉN is 
látom, hogy ez jó. Most, hogy így meggazdagodtam, megnézek 
egy jó filmet. A világgép sok-sok ügynöke lendül munkába a ked- 
vemért, megkeresik a film soronkövetkező darabkáit az Ők számí- 
tógépein és rendületlenül küldik az én hűséges ügynökömnek. A 
közvetítési díjakból az ügynök, azaz K is jól megél. 

Feltűnik a színen az 5. elem, az Internetmumus, a kódtörő Szabó né- 
ni, aki mellesleg P alkalmazottja, és álmatlan éjszakákat tölt főnö- 
ke nem ismert fizetése miatt. Otthoni gépével beáll a sorba, és re- 
ményei végül valóra válnak, nemsokára tényleg ott landol a gépén 
egy, a főnök fizetését leíró darabka. De micsoda bosszúság, csak az 
egyik, és az is titkosítva. Hol van a többi? Ekkor ráébred, az Ők gé- 
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A Farsite egy 
kiszolgáló nélküli, 
a wördöt és a bullbrózert használom). Regiszt- elosztott fájlrendszer 
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pein. Hogy melyikeken, az kemény dió, mert ez dinamikusan változ- 

hat annak függvényében, hogy éppen melyik van bekapcsolva, és az 

ügynökök sem ma jöttek le a falvédőről, tanulják egy ideje a mate- 
matikát. Egy kis bíztatással talán segíthetünk: hajrá Szabó néni! 

Ezen a bolton - Szabó nénit kivéve, aki sokat költhet majd pszicho- 

lógusra - mindenki nyer! A végeredmény egy minden eddiginél 

megbízhatóbb, gyakorlatilag kimeríthetetlen tároló- és feldolgozó- 
rendszer. Ha egészében tekintünk erre a rendszerre, akkor egyetlen 
nagy számítógépet látunk, egy új paradigmát bevezető, világmére- 
tű operációs rendszerrel: ISOS - Internet-Scale Operating System. 

Egy ISOS munkába állíthatná az Internethez kapcsolódó 150 millió 

számítógép összes erőforrását (ez a szám már évek óta hatványozot- 

tan növekszik) , aminek eredményeként egy hihetetlenül nagy kapa- 

citású, virtuális , mainframe" állna a közösség tagjai részére. A vi- 

lággép mindemellett még önjavító is, hiszen ha elromlik a gépem, 

ÉN elviszem megjavíttatni. 

Az ISOS kétféle alkalmazástípusnak kedvez: az elosztott adatfel- 

dolgozásnak és az elosztott online szolgáltatásnak. 

Az utóbbi kategóriába tartozik például a közismert SETKOhome 

projekt, amely a fölösleges processzoridőt a földönkívüli, értelmes 

élet keresésének szolgálatába állítja, vagy a 

distributed.net RSA törögető alkalmazása stb. 

Azt azonban érdemes megemlíteni, hogy lét- 

rejöttüket szinte mindig a feldolgozásra váró, 

petabájtos nagyságrendű adatmennyiségnek 
köszönhetik. 

A Microsoft is megtette már az első lépése- 

ket mindkét fentebb említett területen: 

"0 AFarsite [2] egy kiszolgáló nélküli, elosztott fájlrendszer. A 
résztvevő kliensek között nincs kölcsönös (trust) kapcsolat, de 
mindegyikük hozzáfér a csak logikai síkon létező, központi állo- 
mánykiszolgálóhoz. A Farsite globális, hierarchikus névterében 
könnyű a tájékozódás, nem tudunk, nem tudhatunk, és nem is a- 
karunk tudni arról, valójában melyik kliens tárolja az adatainkat. 

2 Az elosztott online alkalmazások frontján a Pastry [3] áll csa- 
tasorba, amely a résztvevő gépekkel egy elosztott, méretezhe- 
tő, önszervező és hibatűrő réteget biztosít a (peer-to-peer) 
társalkalmazások számára. Hatékonyan valósítja meg a Pastry 
gépek közötti útválasztást, a terheléselosztást és az objektu- 
mok helyének meghatározását. 

A világgép e két lehetséges komponensét a soron következő két 

számban mutatom be részletesebben. 


Zaccoofw.hu 
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Következő számunk tartalmából 


Exchange: 

Tovább mélyedünk az Exchange 2000 rendszerfelügyeleti feladataiba, elérkeztünk a felhasználók tulajdon- 
ságaihoz, megnézzük mit hol lehet beállítani. A felhasználók után a címlistákat fogjuk körüljárni, és ha fut- 
ja erőmből, akkor a házirendekkel is foglalkozunk. 


Jog: 

Április 1-től az eddiginél jóval nehezebb helyzetbe kerülhetnek azok, akik az Internetet hátsó szándékkal 
használják. Ha valamilyen, a Büntető Törvénykönyvben meghatározott tényállást valósítanak meg, akkor 
adott esetben sokéves börtönbüntetéssel is számolhatnak. A korábban ismertek mellett új elkövetési alak- 
zatok is megjelentek a törvényben, ezzel korábban bűncselekménynek nem minősülő magatartások is e kör- 
be kerültek. 


ADO.NET 

A tech.net magazin februári és márciusi számában XMLgessünk címen bemutattuk az ADO.NET adatbázis-ke- 
zelésének központi elemét, a DataSet objektumot. Egy memóriában tárolt adatbázis óriási kincs, de csak ak- 
kor, ha stabil technológiai kapoccsal összeköthető a meglévő adatbáziskiszolgálókkal és a helyi gépeken tá- 
rolt XML állományokkal. A cikk a két kapcsolódási felület közül az elsőt elemzi, és az SOLServer adatbázis 
és a DataSet objektum közötti híd ,aszfaltozási munkálataiba" avatja be az Olvasót 


Szerszámosláda 

Több alkalommal is felmerült a kérdés a NetAcademia listáin, vajon hogyan lehetne megállapítani, hogy egy 
felhasználónak milyen tényleges jogai vannak egy könyvtárban, illetve milyen eszközzel lehetne akár egy 
egész könyvtárstruktúráról is kimutatást készíteni az aktuális hozzáférési szabályokról. Nos, egy beépített 
eszköz és egy szabadon használható szoftver megoldást jelenthet a problémával küzdőknek. 


Farkasokkal táncoló 

Az infrastruktúra területén tett kirándulásunk után visszatérünk az erőforrások világába, és megnézzünk, ho- 
gyan lehet fontos alkalmazásszoftvereknek magas rendelkezésre állást biztosítani. Látni kell, hogy itt már 
nem pusztán egy szolgáltatást hozunk létre, hanem egy teljes alkalmazást helyezünk el fürtözött környezet- 
ben, ez pedig minden eddiginél nagyobb figyelmet követel tőlünk. Két Microsoft terméket és egy harmadik 
gyártótól származó szoftvert vizsgálunk meg. 


Biztonság 

A tech.net magazin III. évfolyamának első számában olvashattuk, hogyan használható a Windows 2000 
IPSEC implementációja, mint egyszerű csomagszűrő. Sajnos ez a tulajdonság csak melléktermék, tervezés- 
kor egyáltalán nem szerepelt a célok között. Ezt hallva az olvasó rögtön gyanút foghat, vajon nem szárma- 
zik-e ebből valami alapvető probléma... 
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RENDSZERHÁZ Kft. 


Tel.: 


Bp. 1055 Honvéd u. 40. fsz. 8. F: 269-3058 


269-2233, 301-0429  Tel.: 382-0313, 382-0314 


Bp. 1119 Etele út 10. Fsz.1. F: 204-9292 





PANNON SUPPORT RENDSZERHÁZ - AZ ÖN MEGOLDÁSSZÁLLÍTÓJA! 


Szolgáltatás, tanácsadás 


Szakembereink (MCP, MCSE) vállalják: 


- új informatikai rendszerek teljeskörű kialakítását, konfigurálását 


meglévő rendszerek bővítését 
- konkurens rendszerek átmigrálását Microsoft megoldásra 


műszaki konzultáció 
szoftver licencelési tanácsadás 
szoftver jogtisztasági vizsgálatot 


Kereskedelem 
- Microsoft licencek (OLP, OSL, OEM, doboz) értékesítése 


- egyéb szoftveres (antivírus, tűzfal, grafikai) megoldások forgalmazása 


- hardverek, hardverkiegészítők kereskedelme 


informatikai rendszerek általánydíjas és alkalmi karbantartását 





Vásároljon IBM szervert Microsoft SBS Server op. rendszerrel! 


IBM xSeries 200 Server (107C252) 


Here 
Business 
Partner 








MS Small Business Server 2000 


Akciós áron, együtt: 


385.000, - 


2000 
— eni 


A feltüntetett árak a 259-os ÁFA-t nem tartalmazzák! Az árváltoztatás jogát fenntartjuk! 


infoBYTE 


A távközlési piac liberalizálása és a mobiltelefőniában várható 
generációváltás érdekegyeztetési törekvéseiről tudósít ez a rovat. 


A hónap vezető cikke új technológiákról, megoldásokról. 
Külfödi hírek, kitekintés. 


Az Informatikai Kormánybiztosság 2001— 2002-ben 
összesen 36 különféle programot koordinál. Az információs 
társadalom kiépítésének lépcsőfokai ezek. 


I I 
Az Inforum célja, hogy párbeszédet folytasson a szakma és a 
kormányzat között. Aktív szerepet vállalt a szerzői jogi, az 
egységes hírközlési és az elektronikus kereskedelmi törvény 
megalkotásában. 


-INFC IKA 
Ebben a rovatban nem elsősorban a technológiára, hanem a meg- 
valósult projektekre, az EU-kompatibilitás kérdéskörére, 
pályázatokra koncentrálunk. 


Az infopen.hu webmagazin és az infoBbYTE közös rovata, 
kifejezetten IT vezetők számára. A rovat egy aktív CIO-val 
készült átfogó interjúval indul, amelyet stratégiai jellegű 
technológiai áttekintések, szakcikkek követnek. A rovat 
hangsúlyos részei a vállalati IT megoldásokat bemutató 
esettanulmányok, de interjúk, konferenciatudósítások 
formájában a piac meghatározó megoldásszállító cégeinek üzleti 
és termékstratégiájának bemutatása is helyet kap. 


Tapasztalatok szerint három-négy évente változtatunk mi, 
informatikusok állást, szakmát vagy szakirányt, és ez a szám a 
jövő évtizedekben valószínűleg csökkenni fog. 


E rovatunkban olvasóink nevében és helyett Novell szakértőket 
kérdez a szerző. 


A NetAcademia-féle mélyvíz-tanfolyamokra iratkozhatnak be 
azon olvasóink, akik Dr. Watson nyomában járnak. 


Hardver- és szöftvertésztek röviden, velősen. 


Sokakat érdeklő CPULújdonságok mélységei 
a fejlesztéshez közel álló szakértők tollából. 


Kérjen mintapéldányt: mintaGinfobyte.hu 
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A projektirányítás számos szervezet sikerében és bu- A Microsoft Project 2000 olyan egységes tervezőesz- 
kásában játszik fontos szerepet. Egy hatékony köz, mellyel a szervezet minden tagja egyszerűen 
tervezési eszköz birtokában csökkenthetők a megtervezheti, módosíthatja, nyomon követ- 
költségek és javítható a termelékenység, heti az adott projektet és annak valamennyi 
ami nyereségnövekedést eredményez. fázisában mérheti annak eredményességét. 


Ismerje meg fő NON tanfolyamainkon! 
eleb 


Microsoft Project 2000 és Project Central kurzusok 


A Microsoft Project témakörben oktatóközpontunkban kétnapos, intenzív tanfolyam keretében ismerkedhet meg a program 2000-es 
verziójának használatával, haladók részére pedig szintén kétnapos Project Central kurzusnkat ajánljuk. 


Rugalmas időbeosztás 

Megpróbáltuk figyelembe venni, hogy a cégek dolgozóikat - különös tekintetettel a vezető/felelős beosztású személyekre - nem tudják 
nélkülözni hosszabb időre, ezért a tanfolyamokat intenzív, egész napos formában hirdettük meg, délelőtt 9.00 és 16.00 óra között. A 
tanfolyamok díja az oktatás és a tananyagok mellett az étkezést is tartalmazza a kurzus napjaira. 


Testreszabott oktatások 


Oktatóközpontunkon kívül, a megrendelő telephelyén, kihelyezett formában (vidéken is) is vállaljuk az adott cégprojektekhez kapcso- 
lódva tanfolyamok vagy konzultációk megtartását, lebonyolítását. Ehhez igazodva készítjük el a tematikát és az oktatási segédletet, így az 
oktatás kedvezőbb időbeosztással és anyagi feltételekkel valósítható meg. 


A képzésekkel, szakmai kérdésekkel kapcsolatosan kérjük keresse értékesítési vezetőnket, Lovász Attilát a 203-0304/3040 mellékű 
telefonszámon. 


Tervezze üzleti folyamatait Microsoft Project 2000-rel! 
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